View CD1865_930589.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

CD1865 intelligent eight-channel communications controller datasheet product features eight full-duplex asynchronous channels supporting data rates up to 115.2 kbps note: to support this data rate, the specified system clock frequency is required. register-based interrupt acknowledges eliminate need for separate interrupt acknowledge signals automatic prioritizing scheme allows device to respond to an interrupt acknowledge with the highest internal interrupt pending (host-programmable) sophisticated interrupt schemes ? vectored interrupts ? fair share interrupts ?good data ? interrupts for improved throughput ? simultaneous interrupt requests for three classes of interrupts: rx, tx, and modem state changes independent baud-rate generators for each channel/direction software compatibility with the cd180 and cd1864 devices generation and detection of special characters automatic flow control ? in-band (xon, xoff generation, and detection) ? out-of-band (dtr/dsr or rts/cts) on-chip fifo ? 8 bytes each for rx, tx, and status line break detection and generation multiple-chip daisy-chain cascading feature odd, even, forced, or no parity modem/general-purpose i/o signals per channel system clock up to 66 mhz (x2), 33mhz (x1) cmos technology in 100-pin mqfp as of may 18, 2001, this document replaces the basis communications corp. document cl-CD1865 ? intelligent 8-channel communications controller . may 2001
datasheet information in this document is provided in connection with intel ? products. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. except as provided in intel?s terms and conditions of sale for such products, inte l assumes no liability whatsoever, and intel disclaims any express or implied warranty, relating to sale and/or use of intel products including liabil ity or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property righ t. intel products are not intended for use in medical, life saving, or life sustaining applications. intel may make changes to specifications and product descriptions at any time, without notice. designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." int el reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. the CD1865 may contain design defects or errors known as errata which may cause the product to deviate from published specifica tions. current characterized errata are available on request. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an ordering number and are referenced in this document, or other intel literature may be obtaine d by calling 1-800- 548-4725 or by visiting intel?s website at http://www.intel.com. copyright ? intel corporation, 2001 *third-party brands and names are the property of their respective owners.
datasheet 3 intelligent eight-channel communications controller ? CD1865 contents 1.0 overview ......................................................................................................................10 1.1 theory of operation ............................................................................................10 2.0 conventions ...............................................................................................................13 2.1 abbreviations.......................................................................................................13 2.2 acronyms ............................................................................................................13 3.0 device selection considerations ......................................................................15 4.0 pin information ..........................................................................................................16 4.1 pin diagram.........................................................................................................16 4.2 pin assignments..................................................................................................17 5.0 functional description ...........................................................................................18 5.1 introduction..........................................................................................................18 5.2 internal operation................................................................................................20 5.3 service request and interrupt operation............................................................26 5.3.1 theory of operation ...............................................................................26 5.3.2 internal implementation of the service request logic...........................28 5.3.3 priorities and fair share.........................................................................31 5.4 types of service requests .................................................................................31 5.4.1 receive service requests .....................................................................32 5.4.2 transmit service requests ....................................................................35 5.4.3 modem signal change service requests..............................................35 5.5 implementing service requests..........................................................................35 5.5.1 method 1a ? full interrupt ? type a, three-level interrupt with three-level acknowledge ..............................................................37 5.5.2 method 1b ? full interrupt ? type b, three-level interrupt with single-level acknowledge ...............................................38 5.5.3 method 2b ? interrupt interface, single-level interrupt with single-level acknowledge ...............................................39 5.5.4 method 3b ? polled interface................................................................40 5.5.5 comparison of interrupt and polled code sequences ...........................42 5.5.6 cascading service requests with multiple CD1865s ............................43 5.5.7 multiple CD1865s without cascading.....................................................44 5.5.8 acknowledging service requests ..........................................................44 6.0 system bus interface and system clock .......................................................46 6.1 system interface considerations ........................................................................47 6.2 system clock and bit rate options ....................................................................47 6.2.1 system clock .........................................................................................47 6.2.2 external clock ........................................................................................47 6.2.3 1 clock option......................................................................................48 6.2.4 bit rate options .....................................................................................48 6.2.5 maximum throughput limits ..................................................................51 6.3 CD1865 basic bus interface and addressing .....................................................51 6.3.1 intel ? versus motorola ? interface signals and addressing ......................51
CD1865 ? intelligent eight-channel communications controller 4 datasheet 6.3.2 unclocked versus clocked bus interface .............................................. 52 6.4 interface examples ............................................................................................. 54 6.4.1 interfacing to 80x86-family processors ................................................ 55 6.4.2 interfacing to 680x0-family processors ................................................ 55 6.4.3 interfacing to the vme bus .................................................................... 55 7.0 serial interfaces ........................................................................................................ 58 7.1 receiver operation ............................................................................................. 58 7.1.1 basic operation...................................................................................... 58 7.1.2 receive fifo operation ........................................................................ 58 7.1.3 fifo timer operations .......................................................................... 60 7.1.4 receive service requests ..................................................................... 60 7.1.5 receive good data ? service request ................................................. 61 7.1.6 receive exception service request ...................................................... 61 7.1.7 types of errors....................................................................................... 62 7.1.8 types of exceptions ............................................................................... 62 7.1.9 flow-control characters ........................................................................ 63 7.1.10 programming notes ............................................................................... 68 7.2 transmitter operation ......................................................................................... 68 7.2.1 basic operation...................................................................................... 68 7.2.2 fifo operation ...................................................................................... 69 7.2.3 transmit service requests .................................................................... 69 7.2.4 special transmitter commands ............................................................. 70 7.2.5 special character transmission by send special character command ................................................................. 70 7.2.6 embedded transmit commands............................................................ 70 7.2.7 sending breaks ...................................................................................... 71 7.2.8 sending inter-character delays ............................................................. 71 7.2.9 summary of special transmitter commands......................................... 71 7.3 flow control ........................................................................................................ 72 7.3.1 receiver flow control ............................................................................ 72 7.3.2 receiver hardware (out-of-band) flow control .................................... 73 7.3.3 receiver software (in-band) flow control............................................. 74 7.3.4 transmitter flow control ........................................................................ 75 7.3.5 transmitter hardware (out-of-band) flow control ................................ 76 7.3.6 transmitter software (in-band) flow control......................................... 76 7.4 modem signals and general-purpose i/o .......................................................... 78 7.4.1 generating service requests with modem pins .................................... 80 7.4.2 using modem pins as general-purpose i/o .......................................... 80 7.5 testing the CD1865 ? loopback tests ............................................................. 80 8.0 programming ............................................................................................................. 83 8.1 types of registers .............................................................................................. 83 8.2 access duty cycle .............................................................................................. 84 8.3 accessing fifos versus other registers .......................................................... 84 8.4 initialization ......................................................................................................... 84 8.5 global register initialization................................................................................ 86 8.6 service request initialization .............................................................................. 86 8.7 prescaler ............................................................................................................. 86 8.8 channel initialization and changes..................................................................... 87
datasheet 5 intelligent eight-channel communications controller ? CD1865 8.9 transmitting data ................................................................................................87 8.10 receiving data ....................................................................................................88 8.11 programming examples ......................................................................................88 8.11.1 programming the service match registers ............................................88 8.11.2 CD1865 initialization ..............................................................................88 8.11.3 basic i/o operations ..............................................................................90 8.11.4 interrupt response operations ..............................................................90 8.11.5 polled mode operation...........................................................................93 9.0 detailed register descriptions ...........................................................................94 9.1 register map quick reference ...........................................................................94 9.2 global registers..................................................................................................97 9.2.1 miscellaneous registers ........................................................................98 9.2.2 configuration registers..........................................................................98 9.2.3 service request/interrupt control registers ........................................103 9.3 indexed indirect registers.................................................................................108 9.3.1 receive data count register...............................................................108 9.3.2 receive data register .........................................................................109 9.3.3 receive character status register ......................................................110 9.3.4 transmit data register ........................................................................111 9.3.5 end-of-service request register.........................................................111 9.4 channel registers.............................................................................................111 9.4.1 enable register...................................................................................112 9.4.2 channel command register ................................................................112 9.4.3 channel option register 1 ...................................................................116 9.4.4 channel option register 2 ...................................................................116 9.4.5 channel option register 3 ...................................................................117 9.4.6 channel control status register..........................................................118 9.4.7 receiver bit register............................................................................119 9.4.8 receive time-out period register.......................................................120 9.4.9 receive bit rate period registers (high/low).....................................120 9.4.10 transmit bit rate period registers (high/low)....................................121 9.4.11 special character register 1 ...............................................................121 9.4.12 special character register 2 ...............................................................122 9.4.13 special character register 3 ...............................................................122 9.4.14 special character register 4 ...............................................................123 9.4.15 modem change register .....................................................................123 9.4.16 modem change option register 1.......................................................124 9.4.17 modem change option register 2.......................................................125 9.4.18 modem signal value register..............................................................125 9.4.19 modem signal value request-to-send register..................................126 9.4.20 modem signal value data-terminal-ready register ..........................126 10.0 electrical specifications ....................................................................................127 10.1 absolute maximum ratings...............................................................................127 10.2 recommended operating conditions ...............................................................127 10.3 dc electrical characteristics.............................................................................127 10.4 index of timing information...............................................................................128 10.5 ac electrical characteristics .............................................................................128 10.5.1 clocked bus interface ..........................................................................128
CD1865 ? intelligent eight-channel communications controller 6 datasheet 10.5.2 unclocked bus interface ...................................................................... 136 11.0 package specifications ....................................................................................... 145 12.0 ordering information ............................................................................................ 146 index ............................................................................................................................... ........ 147 figures 1 functional block diagram ..................................................................................... 9 2 internal block diagram........................................................................................ 22 3 foreground/background internal structure......................................................... 24 4 internal operation flow chart ............................................................................. 25 5 internal service acknowledge decision tree...................................................... 30 6 internal fair-share operation ............................................................................. 31 7 receive timer operation .................................................................................... 34 8 three-level interrupt with three-level acknowledge example.......................... 38 9 three-level interrupt with single-level acknowledge example ......................... 39 10 single-level interrupt with single-level acknowledge example ........................ 40 11 simple software polled interface example ......................................................... 41 12 polled code sequence ....................................................................................... 42 13 interrupt code sequence .................................................................................... 43 14 internal block diagram........................................................................................ 46 15 2 clock option................................................................................................... 47 16 ............................................................................................................................ 4 8 17 typical unclocked bus interface......................................................................... 53 18 typical clocked bus interface............................................................................. 54 19 incorrect vme interface ...................................................................................... 56 20 correct vme interface......................................................................................... 57 21 bit synchronization in CD1865 ........................................................................... 58 22 receive operation .............................................................................................. 59 23 no new data timer logic ................................................................................... 67 24 transmitter operation ......................................................................................... 69 25 receiver flow-control logic ............................................................................... 73 26 transmitter flow-control logic ........................................................................... 76 27 local and remote loopback logic..................................................................... 82 28 initialization ......................................................................................................... 85 29 clocked bus interface reset............................................................................. 130 30 clocked bus interface clocks ........................................................................... 131 31 clocked bus interface read cycle, motorola ? -style handshake ............................................................................... 131 32 clocked bus interface service acknowledgment cycle, motorola ? -style handshake ............................................................................... 132 33 clocked bus interface write cycle, motorola ? -style handshake ............................................................................... 133 34 clocked bus interface read cycle, intel ? -style handshake ...................................................................................... 134 35 clocked bus interface service acknowledgment cycle, intel ? -style handshake ...................................................................................... 135 36 clocked bus interface write cycle, intel ? -style handshake.............................. 136
datasheet 7 intelligent eight-channel communications controller ? CD1865 37 unclocked bus interface read cycle, motorola ? -style handshake...................139 38 unclocked bus interface service acknowledgment cycle, motorola ? -style handshake ...............................................................................140 39 unclocked bus interface write cycle, motorola ? -style handshake ...............................................................................141 40 unclocked bus interface read cycle, intel ? -style handshake..........................142 41 unclocked bus interface service acknowledgment cycle, intel ? -style handshake ......................................................................................143 42 unclocked bus interface write cycle, intel ? -style handshake144 tables 1 cd18xx product family .....................................................................................15 2 differences between the CD1865 and cd1864..................................................15 3 state machine logic............................................................................................29 4 service request methods ...................................................................................36 5 bit rate constants, clk = 33 mhz .....................................................................49 6 bit rate constants, clk = 25 mhz .....................................................................49 7 bit rate constants, clk = 20 mhz .....................................................................50 8 bit rate constants, clk = 15 mhz .....................................................................50 9 register summary...............................................................................................96 10 clocked timings................................................................................................129 11 unclocked timings ............................................................................................137
CD1865 ? intelligent eight-channel communications controller 8 datasheet revision history revision date description 1.0 may 2001 initial release.
intelligent eight-channel communications controller ? CD1865 datasheet 9 figure 1. functional block diagram serial interface serial interface serial interface serial interface serial interface serial interface serial interface serial interface ram firmware rom risc processor host bus interface logic 5 5 5 5 5 5 5 5 txd rxd modem txd rxd modem txd rxd modem txd rxd modem txd rxd modem txd rxd modem txd rxd modem txd rxd modem reset* cs* ds* clk* r/w* a[0:6] intel/mot* rreq* treq* mreq* dtackdly dtack* db[0:7] ackin* ackout* clk osc1 osc2 dblclk ckout
CD1865 ? intelligent eight-channel communications controller 10 datasheet 1.0 overview the CD1865 is a cost-effective controller capable of controlling eight full-duplex channels transferring data at rates up to 115.2 kbps. the advantage of the CD1865 lies in its ability to efficiently move data from the serial channels to the host. this results in an order-of-magnitude improvement in system-level throughput and a reduction in overhead on the host cpu. to increase the overall data throughput of the system, the device relies on a combination of features. most important are the buffers for transmit and receive data. each serial channel has three 8-byte fifos ? one each for transmit, receive, and receive exception status. the receive fifos have programmable thresholds to minimize interrupt latency requirements. the CD1865 is based on a high-performance proprietary risc processor architecture developed by intel specifically for data communication applications. this processor executes all instructions in one clock cycle, and uses a register-window architecture to ensure zero-overhead context switch for each type of internal interrupt. the CD1865 is fabricated in an advanced cmos process. the device ? s high throughput, low- power consumption, and high-level of integration permit system designs with minimum parts count, maximum performance, and maximum reliability. 1.1 theory of operation the CD1865 custom risc processor is assisted by specialized peripheral logic. serial data transmission and reception is handled by ? bit engines ? . each channel has a bit engine for transmit and another for receive. while each engine handles all bit-level timing, bit-to-character assembly is done in firmware. bits are passed to the processor by internal interrupts, over a special bus dedicated to this purpose. to reduce internal interrupts to zero, special interrupt context hardware points to the correct register window for every possible context. a unique global index register eliminates address calculations by always pointing to the current channel. the processor assembles bits into characters, checks parity and other formatting parameters, and stores the data in the fifos as required. fifos are maintained as ram-based structures. both the local processor and the host access them by pointer registers, in effect an indexed addressing mode. the CD1865 communicates with the host by service requests and service acknowledgments. service requests can be detected by interrupt lines or by on-device registers. regardless of the method used, the CD1865 has features to minimize both the number of requests to be serviced and the time required to service them. fifos help reduce the number of service requests to one every eight characters. to reduce the time required per request, the CD1865 supplies separate vectors for four different types of service requests. this reduces the time required by the processor to effect the proper operation. for instance, there is a unique vector for ? good data ? , so that the host wastes no time checking status bits or error conditions. if there is an error condition, the CD1865 supplies a unique vector pointing to the error-handling routine. other vectors report transmit status and modem signal change. interrupts can be acknowledged either by an interrupt acknowledge pin, or by reading an on- device register. this allows host software maximum flexibility and speed in handling service requests.
intelligent eight-channel communications controller ? CD1865 datasheet 11 because the CD1865 risc processor is processing every character sent or received, features such as automatic flow control and special character recognition are easily implemented. this further reduces the processing burden on the host system. both in-band (xon, xoff) and out-of-band (rts/cts, dtr) flow-control modes are supported. for in-band flow control, the CD1865 automatically starts and stops its transmitter when the remote unit sends flow-control characters. the CD1865 also makes it easy for the local host to flow-control the remote, by the ? send special character ? commands. for out-of-band flow control, the transmitter optionally asserts rts and monitor cts for permission to send; and assert/negate dtr when the receive fifo reaches a user- definable threshold. together, the in-band and out-of-band features not only allow the data flow to be controlled in real time with minimum or no host intervention, it also prevents loss of data. as shown on the previous page, the CD1865 can interface virtually any cpu, with a minimum of glue logic. refer to the CD1865 data sheet for detailed information on how to interface various microprocessors. systems with multiple CD1865s are easily implemented, with no external glue, by device a daisy-chain scheme. a ? fair share ? feature ensures equal access for all service requests, both within one CD1865 and across multiple devices. fifo ? 24 bytes of fifo are dedicated to each channel partitioned as 8 bytes for transmitter, 8 bytes for receiver, and 8 bytes for status. the receive fifo has a user-programmable threshold to optimize system response and latency. the receive fifo threshold programming range is from 1 ? 8 characters. vectored interrupt structure ? three interrupt signals ([r, t, m]req*) are used. these signals may also be read as an on-device register. each req* signal represents one of three interrupt groups: receive, transmit, and modem signal state changes. upon servicing by the host, an interrupt vector is generated by the CD1865 to define the interrupt group to be serviced and which CD1865 generated the interrupt. this allows the host software to enter directly into the proper interrupt service routine, reducing the amount of interaction between the host and the controller, and determining the nature of the interrupt. good data interrupt ? if data received is all good, the host is advised of the number of good data bytes in the fifo, allowing the host to read data without further status queries until all good data has been transferred. fair-share interrupt scheme ? to ensure equal service of all channels, a fair share scheme is used for each interrupt group. no channel can interrupt for the same condition until all others have a chance to be serviced for the same interrupt condition. typical CD1865 host cpu interface CD1865 in daisy-chain scheme address data cs* ds* r/w dtack* ackin* rreq* treq* mreq* CD1865 cpu interrupt controller address decode and logic txd rxd dtr* dsr* rts* cts* cd* channel 1 channel 2 channel 3 channel 4 channel 5 channel 6 channel 7 channel 0 CD1865 CD1865 CD1865 rreq* treq* mreq* interrupt controller cpu ackin* ackout* ackin* ackout* ackin* ackout* rreq* treq* mreq* rreq* treq* mreq* control
CD1865 ? intelligent eight-channel communications controller 12 datasheet note: to support 115.2 kbps, a system clock of 66 mhz is required. system design is simplified in the CD1865 by providing a choice of crystal or external clock operation, at 1 - or 2 -rated frequency.
intelligent eight-channel communications controller ? CD1865 datasheet 13 2.0 conventions 2.1 abbreviations the use of ? tbd ? indicates values that are ? to be determined ? , ? n/a ? designates ? not available ? , and ? n/c ? indicates a pin that is a ? no connect ? . 2.2 acronyms symbol units of measure c degree celsius fmicrofarad s microsecond (1,000 nanoseconds) hz hertz (cycle per second) kbit kilobit (1,024 bits) kbps kbits/second kilobit (1,000 bits) per second kbyte kilobyte (1,024 bytes) kbytes/second kilobyte (1,000 bytes) per second khz kilohertz k ? kilohm mbyte megabyte (1,048,576 bytes) mhz megahertz (1,000 kilohertz) ma milliampere ms millisecond (1,000 microseconds) ns nanosecond pv picovolt vvolt wwatt acronym definition ac alternating current cmos complementary metal-oxide semiconductor dc direct current dma direct-memory access dram dynamic random-access memory fifo first in/first out
CD1865 ? intelligent eight-channel communications controller 14 datasheet hdlc high-level data link control isa industry standard architecture lsb least-significant bit msb most-significant bit ppp point-to-point protocol mqfp metric quad flat pack ram random-access memory r/w read/write sdlc synchronous data link control ttl transistor-transistor logic acronym definition (continued)
intelligent eight-channel communications controller ? CD1865 datasheet 15 3.0 device selection considerations the CD1865 device is an enhanced version of the same product family as the cd180 and cd1864. the CD1865 is software compatible with both the cd180 and cd1864. if this is a new CD1865 design, please skip this page. the CD1865 is recommended for any new designs. please note that to achieve the high data rates, 66-mhz system clock is required. to support data rates of up to 115.2 kbps, the specified system clock frequency is required. please refer to the differences in pins between the cd1864 and CD1865. it is recommended that the 66-mhz, 2 -clock option (oscillator or crystal) is used wherever possible. note: this input (dtrsel) on the cd180 sets the mode for the dtr*/cd* pins. when dtrsel is high, the dtr*/cd* pins implement the dtr* output; when low, the dtr*/cd* pins become cd* inputs. the cd1864 and CD1865 have separate dtr and cd pins and so the dtrsel is eliminated. note: in january 1995, intel changed all 100-pin pqfp package types from eiaj to jedec. the CD1865 is now available in a jedec package. before beginning any new design or converting from cd1864 to CD1865, please contact intel for package details. warning: the CD1865 device may have potential latch up problems if used in socket. it is recommended that this device be surface mounted. table 1. cd18xx product family features cd180 cd1864 CD1865 package 84-pin plcc 100-pin pqfp 100-pin mqfp system clock 12.5 mhz 25 mhz ( 2) or 12.5 mhz ( 1) 66 mhz ( 2) or 33 mhz ( 1) maximum bit rates 64 kbps 64 kbps 115.2 kbps pins dtrsel * ?? 4 modem/io signals per channel 5 modem/io signals per channel 5 modem/io signals per channel table 2. differences between the CD1865 and cd1864 pin number CD1865 pin name cd1864 pin name comments 1v cc n/c note 1 16 gnd n/c note 1 37 v cc n/c note 2 notes: 1. pin 1 and pin 16 are truly no-connects on the cd1864 device. 2. pin 37 on the cd1864 is not a true no-connect, and can cause problems if connected to v cc . to make a single board design be compatible with either the cd1864 or CD1865, a configuration jumper must be used to allow pin 37 to be a no-connect or a v cc connection.
CD1865 ? intelligent eight-channel communications controller 16 datasheet 4.0 pin information the CD1865 is available in a 100-pin mqfp (metric quad flat pack device) configuration as shown below. 4.1 pin diagram note: (*) denotes an active-low (negative-true) signal. CD1865 100-pin mqfp txd[1] gnd rts[5]* vcc nc dtackdly gnd intel/mot* dsr[4]* dtr[4]* cts[7]* cd[7]* dtr[7]* dsr[7]* rxd[0] osc2 osc1 no_osc dblclk ackin* rxd[1] rxd[6] txd[2] txd[7] txd[6] rxd[2] rxd[7] txd[3] mreq* db[6] 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 1 2 3 4 5 6 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 80 79 78 77 76 73 72 74 75 71 70 68 67 65 63 62 61 60 59 58 57 55 53 52 51 69 66 64 56 54 gnd test a[6] a[5] a[4] a[3] a[2] a[1] a[0] db[7] rts[1]* cts[1]* dtr[1]* vcc gnd dsr[1]* rts[2]* cts[2]* dtack* cs* cts[0]* cd[2]* dtr[2]* dsr[2]* rts[3]* cts[3]* cd[3]* dtr[3]* dsr[3]* rts[4]* cts[4]* cd[4]* rts[7]* dsr[6]* dtr[6]* cd[6]* cts[6]* cts[5]* cd[0]* r/w*(wr*) cd[5]* dtr[5]* dsr[5]* rts[6]* cd[1]* rxd[5] dtr[0]* dsr[0]* db[4] ackout* rxd[3] txd[0] txd[4] treq* rxd[4] vcc txd[5] rreq* rts[0]* db[5] clk reset* ds*(rd*) vcc gnd ckout db[0] db[1] db[3] db[2]
intelligent eight-channel communications controller ? CD1865 datasheet 17 4.2 pin assignments the following conventions are used in the table below: (*) denotes an active-low signal; i = input; i/o = input/output; o = output; od = open drain; a (:) indicates decending pin numbers; a ( ? ) indicates ascending pin numbers.
CD1865 ? intelligent eight-channel communications controller 18 datasheet 5.0 functional description 5.1 introduction the CD1865 i/o coprocessor controls eight full-duplex channels that transfer data at rates up to 115.2 kbps. the CD1865 efficiently moves data between the serial channels and the host, resulting in a great improvement in system-level throughput and a reduction in overhead on the host cpu. this improvement is obtained by reducing the number of service requests (interrupts) the host must respond to and reducing the complexity and time required to handle each service request. the CD1865 relies on a combination of features to reduce the number and complexity of service requests. most important are the buffers for transmit and receive data. each serial channel has three 8-byte fifos ? one each for transmit, receive, and receive-exception status. the receive fifos have programmable thresholds to minimize interrupt latency requirements. the vectored service requests and the good data ? interrupt allow the host system to immediately transfer data upon beginning processing of a service request, without tedious checking of flags and error conditions. the CD1865 is based on a high-performance, proprietary risc processor architecture developed by intel specifically for data communications applications. the CD1865 processor executes all instructions in one-clock cycle, and it uses a register window architecture to ensure zero-overhead context switch for each type of internal interrupt. the instruction set of this processor is optimized for bit-oriented tasks that combined with instantaneous response to sending or receiving one bit, allow highly efficient processing of characters. all firmware for the CD1865 processor is contained in an on-device rom, and requires no user programming. the CD1865 processor is assisted in its task by specialized peripheral logic. serial data transmission and reception is handled by ? bit engines ? . each channel has a bit engine for transmitting and another for receiving. while each engine handles all bit-level timing, bit-to- character assembly is done in firmware. bits are passed to the CD1865 processor by internal interrupts over a special bus dedicated to this purpose. special internal-interrupt context hardware reduces overhead on internal interrupts to zero by pointing to the correct register window for every possible context, and a unique global index register eliminates address calculations by always pointing to the current channel. external service requests to the host system are also hardware assisted. there is a queue for each of the three classes of external service requests, and the request/ acknowledgment mechanism is entirely in hardware to minimize response time. the CD1865 processor assembles bits into characters, checks parity and formatting parameters, and stores the data in the fifos as required. fifos are maintained as ram-based structures, and both the local CD1865 processor and the host access them by pointer registers by an indexed addressing mode. the CD1865 communicates with the host by service requests and service acknowledgments. service requests can be handled either as interrupts or by polling. regardless of the method used, the CD1865 has features to minimize both the number of requests to be serviced and the time required to service them. the number of service requests is reduced by the fifos since a service request is required only every eight characters. to reduce the time required per request, the CD1865 supplies separate vectors for four different types of service requests. this reduces the time required by the host cpu to determine what action to take. for example, there is a unique vector for good data so that the host wastes no time checking status bits for error conditions. if there is an error condition, the CD1865 supplies a unique vector pointing to the error-handling routine. other vectors report transmit status and modem signal change.
intelligent eight-channel communications controller ? CD1865 datasheet 19 service requests to the host system are implemented on the CD1865 by three hardware service request state machines. each machine has the ability to ? queue-up ? multiple requests. the state machines are designed to offer the fastest response possible. whenever the CD1865 processor determines that a condition needs a service request, it queues the request with the appropriate state machine. the state machine posts the external request, monitors acknowledgment cycles from the host, and informs the CD1865 processor when a valid service acknowledgment has been completely serviced. this allows the CD1865 to correctly maintain the internal context for processing the channel being serviced. because the CD1865 processor processes every character sent or received, features such as automatic flow control and special character recognition are easily implemented. this reduces the processing burden on the host system. both in-band (xon, xoff) and out-of-band (rts/cts, dtr/dsr) flow control modes are supported. for in-band flow control, the CD1865 automatically starts and stops its transmitter when the remote unit sends flow-control characters. the CD1865 makes it easy for the local host to flow-control the remote by the ? send special character ? commands. for out-of-band flow control, the transmitter optionally asserts rts and monitors cts for permission to send, and assert/negate dtr when the receive fifo reaches a user-definable threshold. dsr can be used to gate the receiver on and off. together, the in-band and out-of-band features allow the data flow to be controlled in realtime with minimum or no host intervention, and this also prevents loss of data. systems with multiple CD1865s are easily implemented, with no external glue, by a daisy-chain scheme. a fair-share feature ensures equal access for all service requests, both within one CD1865 and across multiple devices. alternately, multiple CD1865s can be operated in parallel as independent devices. serial channels on the CD1865 are entirely independent of one another. any channel can be programmed to a combination of features regardless of the state of other channels. bit-rate generators are programmed by loading a divisor value, so the transmitters and receivers can each operate at any standard or non-standard data rate. the CD1865 can detect the received line-break condition, send break characters of any length, and transmit delays. this is done by transmit commands embedded in the transmit data stream. the CD1865 can also be programmed to detect user-defined special characters and generate a special service request to the host. parity checking is performed automatically, but can be overridden by the host to force parity errors for test purposes. character length and stop bit length are also programmable per-channel. modem pins on the CD1865 are general-purpose, that is, they are not hard-wired into the uart functions. if modem pins are not needed to interface to actual modems, they can be used as general-purpose i/o pins. in either case they are readable and writable directly by the host system. in addition, the CD1865 can be programmed to monitor levels on modem input pins and generate service requests to the host upon detecting a specified change. the CD1865 is fabricated in an advanced cmos process. its high throughput, low-power consumption, and high level of integration permits system designs with minimum parts count, maximum performance, and greater reliability. there is a significant difference between the CD1865 and conventional dumb uarts; the CD1865 is more efficient and intelligent, even when operating in a polled environment. systems built with the CD1865 interface between the host and the i/o device at a higher level than systems built with conventional uarts. for example, with a dumb uart, the host must test each channel for presence of data, a process that is time-consuming. with the CD1865, the host queries the entire
CD1865 ? intelligent eight-channel communications controller 20 datasheet serial i/o subsystem for the presence of data. if data is present, the CD1865 determines which channel it is on, and whether it is good or erroneous. thus, using the CD1865, the host-peripheral interface is easier to implement, faster, and more efficient. 5.2 internal operation the internal architecture of the CD1865 is shown in figure 2 . the foundation of the design is a custom-designed cpu that intel has developed especially for this application. this cpu is optimized for bit-oriented tasks associated with uart functions, and it has a set of registers for each channel, arranged in a register window architecture. these registers and the alu are eight bits wide. the CD1865 processor has a 16-bit instruction word that it retrieves from an on-device rom. every instruction is one-word long and executed in one-clock cycle. whenever an internal interrupt occurs (from a bit engine), the CD1865 processor automatically switches context to that channel ? s block of registers. no time is lost in saving any machine state. the CD1865 processor executes the instructions necessary to handle that bit (typically three to six instructions) and then returns to the context it was in prior to the internal interrupt. all internal interrupts are at the same priority level; the interrupt handler block ensures fair-share access across channels. each channel ? s serial interface logic consists of a receive-bit engine, a transmit-bit engine, a receive-baud-rate generator, a transmit-baud-rate generator, and a timer. the receive-bit engine samples the state of the rxd pin at the time indicated by the receive-baud-rate generator, and it reports this value to the CD1865 processor as an interrupt. the transmit-bit engine works in a similar manner. at the baud rate tick, it outputs the next bit and generates an interrupt to the CD1865 processor requesting the following bit. the baud-rate generators are 16-bit dividers that operate from a master clock, which is the system clock divided by 16. all baud-rate generators are independent, so a channel can send and receive at any speed. in addition to the baud-rate generators, there are two channel timers for each channel. one is an 8-bit divider, operating off the master prescaler timer tick. this timer is used to time-out partially full fifos to avoid ? stale ? data. the other is used to time embedded delays in the transmit data stream. all eight channels are continuously scanned by internal logic that generates interrupts to the CD1865 processor in a ? fair ? manner. this fair-share interrupt feature is the same as the mechanism used to share service requests across multiple devices. whenever two or more channels are contending for interrupt service, the channel that is serviced first does not assert again until all other currently pending channels are serviced. this prevents a fast, 64-kbps channel from demanding service from a slow 1200-bps channel, yet it allows the faster channel the additional service it needs to support its higher speed. this allows more overall throughput than a ? round- robin ? or an ? equal-access ? method would provide. service requests for the host are handled by fast, dedicated logic on each of the three levels provided. whenever the CD1865 processor detects a condition requiring external-host service, it queues the request with the service-request machine for that level. this machine asserts the external request pin, and it monitors for a service acknowledgment of the same level. when a service acknowledgment is sensed, the machine automatically provides the vector to the host and sets up the internal context of the CD1865 for service. upon completion of the service, the machine restores the normal context. the queue for service requests is two deep, so in a busy system there can be another request immediately pending when the first one is completed. this method avoids any delay between requests, and improves overall efficiency.
intelligent eight-channel communications controller ? CD1865 datasheet 21 modem i/o signals are implemented as ? conventional ? input-output circuits, readable, and writable by either the on-device or the host cpu. this allows maximum flexibility in using these signals either in the conventional way, or for any other i/o function required. when the CD1865 processor is using these pins to implement flow-control functions, it reads them under software control and implements the function that way. there is no direct hardware association between the modem pins and the serial i/o hardware.
CD1865 ? intelligent eight-channel communications controller 22 datasheet figure 2. internal block diagram cpu rom ram i/o pins (modem control) transmit service request queue receive service request queue modem service request queue bus interface service request logic rts* cts* dtr* dsr* cd* 5 lines 5 lines 5 lines 5 lines 5 lines 5 lines 5 lines cs* ds* r/w dtack* intel/mot* reset* clk dblclk no_osc osc1 osc2 adr[0?6] data[1?7] rxdata txdata rreq* treq* mreq* ackout* ackin* per channel timer receive bit transmit bit dual-baud rate generators interrupt handler engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata
intelligent eight-channel communications controller ? CD1865 datasheet 23 the CD1865 workload can be divided into two categories: bit-to-character conversion (and vice versa) ? the ? traditional ? uart function character-level processing such as flow control, fifo management, and host interface functions the CD1865 internal processor handles all these tasks in firmware. a foreground/background scheme is used: foreground for internal bit-engine interrupts and background for everything else. this internal structure represented in figure 3 on page 24 , shows how the foreground communicates with the background. foreground code handles bit-to-character assembly for receive, and character-to-bit disassembly for transmit. in either case a holding register, together with a full/empty bit, acts as the ? gateway ? between the interrupt-driven foreground and the polling-loop background code. the background code executes the polling loop as shown in figure 4 . after power-on reset, the software runs continuously in an inner and an outer loop. lower-priority tasks are handled in the outer loop, and higher-priority tasks are handled in the inner loop. the highest-priority tasks are bit events that are handled by foreground (that is, interrupt-driven) code. the inner loop executes eight times as often as the outer loop. it checks each channel ? s full/empty bits to sense if another character needs to be moved. it first checks receive, and if there is a character to be moved, it is moved and execution moves on to the next channel. if receive data does not need processing, then transmit is checked. this mechanism gives a slightly higher priority to receive than to transmit, and is favorable because missing a receive character is a fatal error and being late in transmitting one is not an error. (the effect of this can be observed by programming the CD1865 for higher-than-rated serial baud rates and providing a source of receive traffic with virtually 100-percent loading. as the CD1865 is heavily loaded, it leaves short gaps between transmit characters because the firmware is following the ? receive ? path through the code. refer to section 6.2.5 for details on maximum performance and maximum line speed). after eight passes through the inner loop (for example, checking all eight channels for data), one pass is made through the outer loop. this pass checks one channel for host commands (such as ? send special character ? ), timer functions, and a condition that requires posting an external service request (for example, receive fifo full, transmit fifo empty, modem signal change, and so on). if required, the firmware posts the service request within the queue of the appropriate service- request logic. it then continues normal operation, until the host responds to the service request. after a single pass through the outer loop, eight passes through the inner loop are again made. in most cases the CD1865 checks the appropriate bit in ram to determine which options are enabled and then modifies its processing accordingly. some control bits must be interpreted and moved by the CD1865 firmware from their location in option bit registers to other locations in the device. therefore, the host must notify the CD1865 when these bits are modified. then, the CD1865 alters the channel as commanded. for details on channel command functions, refer to section 7.2 .
CD1865 ? intelligent eight-channel communications controller 24 datasheet figure 3. foreground/background internal structure full / empty bit transmitter holding register tranmsitter shift register transmitter fifo background code: fifo-to-h.r. transfer, flow control, other features foreground code: bit disassembly, h.r.-to-s.r. transfer (polling loop) (interrupt-driven) rts out cts in receiver shift register receiver holding register full/ empty bit receiver receive data count register background code: h.r.-to-fifo transfer, flow control, other features foreground code: bit assembly, s.r.-to-h.r. transfer (interrupt-driven) (polling loop) dtr out dsr in receive status fifo receiver transmitter fifo
intelligent eight-channel communications controller ? CD1865 datasheet 25 figure 4. internal operation flow chart initialization for outer_loop i = 1 to 8 for inner_loop j = 1 to 8 if rcv_hld_reg = full if xmt_hld_reg = empty process receive char.; check all special features; place in fifo process transmit char.; check all special features; fetch from fifo y n y n receive service request scanning transmit service request scanning modem service request scanning power-on reset global (software) reset host command processing timer functions process receive interrupt
CD1865 ? intelligent eight-channel communications controller 26 datasheet 5.3 service request and interrupt operation the CD1865 enhances design efficiency, because it is an intelligent device that more closely resembles an add-in controller board than a mere collection of ttl. conventional uarts are basically passive, ? dumb ? logic. for example, when polling a device for channels requiring service, each channel is not individually tested. because of this, certain restrictions are placed on when and how fifos are accessed. the CD1865 processor must determine what the host is doing, and when to manage the queue of events correctly and efficiently. interrupt-driven versus polled choosing the software interface, interrupt-driven versus polled, is critical to overall system performance. this choice also affects how the software is written. in hardware implementation, a programmer has a choice of mixed mode, that is, when to poll versus when to be interrupt-driven. mixed-mode operation allows a programmer to optimize the efficiency of the system according to changing needs. the advantages of each method are discussed in section 5.5 . 5.3.1 theory of operation the CD1865 has three independent service request levels, one for each of the three categories ? receive, transmit, and modem signal change. the priority of these lines is not fixed, but can be determined in one of the following three ways: it can be set within the CD1865 by the autopriority option bits. a system designer can assign priorities by the manner in which the three service request lines are connected to the host interrupt controller. under software control, the host system can define and redefine the order of service requests. the service request interface to the host is implemented with five signals ? *, *, *, ackin*, and ackout*. *, *, and * are asserted when a service request is pending; ackin* is asserted during service-acknowledgment cycles; and ackout* is used in multiple CD1865 designs to share service requests and daisy-chain acknowledgments. whenever the CD1865 processor determines that one or more channels need service from the host, it loads the appropriate service-request state machine with the information about the type of request. the service-request state machine for that level then asserts its request signal. note that all three request signals can be active at the same time. at this point, the CD1865 has not determined which request should be handled first ? it simply asserts any and all lines, as required by the status of various channels. (this is true even if the autopri option is enabled; autopri takes effect when a service request is acknowledged, and at that time the CD1865 determines which is the most important request.) the host, after noticing that one or more of the three service request pins are active ? either because the host is interrupted or it polled an external or internal CD1865 status register ? decides which of the requests (if more than one is active) it services first. the host begins the service operation by issuing a service acknowledge cycle. the purpose of this cycle is to cause the CD1865 to set up its internal state for that type of request. (note that if autopri is set, it is not necessary for the host determine which level of service request to acknowledge; it simply acknowledges the CD1865 request and the CD1865 returns the vector for the highest-priority active request.)
intelligent eight-channel communications controller ? CD1865 datasheet 27 if autopri is not being used, the CD1865 needs to be informed which one of the three possible pending requests the host wants to acknowledge. there are two different ways CD1865 can be informed of this ? hardware and software. the hardware method is based on the value in the address bus. the CD1865 determines the type of request being acknowledged by the value placed in the address bus during the acknowledge cycle. this is the method used by motorola ? -family processors. the host places the level of interrupt being serviced on the low-order address bits during an interrupt acknowledgment cycle. when the host performs a service acknowledge cycle, the CD1865 compares the value on the address bus with the three unique values stored in three internal registers ? the . these values are set by the user at system initialization. a match occurs on only one of these registers, and this informs the CD1865 of the type of request being acknowledged. in most circumstances the address bus should not have a value that does not match one of the three values during an acknowledgment cycle. this causes the CD1865 to not recognize that any bus cycle is occurring, and it does not assert dtack*, or terminate the cycle, or take any other action. doing this does not affect the CD1865, but the system must have some other provision to terminate the bus cycle. if, for example, the CD1865 shares an interrupt level with another device, different values on the address bus should be used to control responses to an acknowledgment, but the bus cycle should terminate in a usable way. service acknowledgments can also be performed by software. the host simply reads one of three request acknowledge registers, and the CD1865 performs as if a hardware service acknowledge cycle is executed. regardless of the method of acknowledgment used, within the CD1865, each service request state machine makes the following determination: if it has an internal service request pending, and there is a service acknowledge of the same type, it asserts its internal-acknowledge-accepted signal back to the service request controller logic, negates the service request output pin, and holds its acknowledge-out daisy chain in a negated state. it also drives the value in the global vector register (gvr) onto the data bus, for the host to read as part of the service acknowledge cycle. the gvr value placed on the bus during the service acknowledge cycle serves two purposes. the least-significant three bits of gvr indicate which of the four types of service requests are occurring. the upper-five bits are user-defined and serve to identify, in daisy-chained CD1865 systems, which of the multiple CD1865s is active. if the service request state machine does not have a service request pending, and there is a software acknowledgment or address bus match, it passes the service acknowledgment down the chain by asserting ackout*. if there is no match, the state machine remains idle. if a service request is pending and the receive service request is to be handled, the CD1865 is notified because the three have different values in them; therefore, only one match (receive service, in this case) occurred. the internal grant from the service request state machine causes the receive service type code and active channel number (previously stored at the time the request is posted by the CD1865 processor) to be pushed onto the service request stack. this automatically causes the fifo pointers to be set up for the active channel, with no host intervention. the host, at this point, has all the information needed to handle the service request. it determines the exact type of service being requested (transmit, receive good data, receive exception, or modem signal change) and which of the multiple CD1865s is requesting service. it gets the channel number by reading the global channel register (gcr) and then proceeds to service the request. at the completion of the service, the host performs a dummy write to the CD1865 end of register (), that causes the CD1865 to exit its internal service request state by popping the service
CD1865 ? intelligent eight-channel communications controller 28 datasheet request stack. at this time the CD1865 is ready to be serviced on another of its outstanding requests. if another request of the same level is pending, two clock periods after the write to are required for the CD1865 to reassert the request line. because the CD1865 has a service request stack, it can support nested-service requests. for example, the host can be in middle of a transmit service request, detect that receive service request has asserted, process the receive service request, and after exiting the receive service routine, resume the transmit service request. the CD1865 stack is three deep, so all three types (one of each) can be nested if required. the current service request context (for example, the stack) is readable in the service request status register. the global channel registers (gcr) are actually three registers that provide the number of the channel requesting service. reading any of these registers causes the CD1865 to mask in three bits, specifying the channel number of the currently active channel. normally these registers are read by the host when it is handling a service request. in this case, the three bits are the number of the channel requesting service. if any of the three gcr registers are read when the CD1865 is not in a service-request context, the three bits are the current value in the car. the current channel number is masked into the contents of bits 4:2 of this register by the CD1865 when it is read by the host. the actual contents of the register are not modified. these three registers are provided as a convenience to the user. in most applications, the user only uses one of these locations, and set the register to some arbitrary value. however, it may be useful to record information about the state of the CD1865 (or the software driving it) that is associated with each of the three service-request types. in this case, the user can store whatever information is required in the unused bits. then, when entering a service routine, the software can check these bits to find what state they were left in, and this could be used as a ? sub-vector ? . 5.3.2 internal implementation of the service request logic as discussed above, the heart of each service request level is an asynchronous state machine. this state machine has three inputs: match from the priority interrupt level register comparator, ackin* from the host system, and internal_request from the CD1865. note: software acknowledgments (reads from the service request acknowledge registers), in effect, force the match value true for their respective level. it also has three outputs: svc_req to the host system, internal_grant to the CD1865, and ackout*, which is combined with the other two ackout* signals to provide ackout* to the next CD1865 in the daisy chain. figure 5 on page 30 shows logic implemented by the state machine, which is described in table 3 .
intelligent eight-channel communications controller ? CD1865 datasheet 29 note: the ( ? ) denotes the point at which, if there is no match, the CD1865 determines not to pass the ack down the daisy chain. it does this for two reasons: first, it is unacceptable to have the ackout* ? glitch ? low; and second, the state machine should be as fast as possible. when the state machine senses an ackin* and match is not valid, it cannot conclude that it should assert ackout*; the ackin* may be for one of the other two service requests levels. it could wait for the results of the other two match comparators; however, this complicates, and therefore slows down, the response of the state machine. the reason this complication causes delay is (to implement the logical function ? assert ackout* if no match ? ) it must determine how long to wait before declaring a no-match condition. to implement this delay function, a synchronous state machine is required, which at a 15-mhz clock, means a delay of several hundred nanoseconds from ackin* to ackout*, instead of the 65 ns currently specified. table 3. state machine logic state name output condition comments idle if (internal_request = 1) else if (ackin* = 1 & match =1) else all outputs inactive goto req_active goto pass_ ack stay at idle ; normal ? resting ? state ; pass this acknowledge ; wait here req_active if (ackin* = 1 & match =1) if (ackin* = 1 & match =0) else goto keep_ack stay at req_active stay at req_active request asserted ; keep this acknowledge ; wait here, ack is for some other level ( ? ) ; wait here pass_ack if (ackin* = 0) else goto idle stay at pass_ack ackout* asserted ; return when ackin* is gone ; wait here while ackin* active keep_ack if (ackin* = 0) else goto idle stay at keep_ack internal_grant asserted ; return when ackin* is gone ; wait here while ackin* active
CD1865 ? intelligent eight-channel communications controller 30 datasheet figure 5. internal service acknowledge decision tree idle state (1) all outputs inactive request_active state (2) assert request pass_ack state (3) assert iackout* keep_ack state (4) assert internal_grant if internal_request = active if iackin* = active and match = yes if iackin* = active and match = no if iackin* = inactive if iackin* = active and match = yes if iackin* = inactive true false true true false false true false true false true false (this block is redundant. it is placed here to emphasize that if there is no match, nothing happens.)
intelligent eight-channel communications controller ? CD1865 datasheet 31 5.3.3 priorities and fair share the CD1865 implements a fair-share mechanism to ensure that all channels receive equal service, without any ? data starvation ? . fair share works automatically among the channels in one device and across multiple devices. figure 6 on page 31 shows a fair-share operational block diagram. on each of the three service request lines, the CD1865 monitors both the internal and external value of the line. (the external value can differ because, in multiple CD1865 applications, it can be driven by other CD1865s.) at the end of a service acknowledgment bus cycle, the CD1865 checks the state of both request values. if they are different, the CD1865 determines that there is another part also driving the request line, and it does not reassert its own request line until the external request has gone inactive. this inactive level means every other CD1865 with a pending request is serviced; therefore, it is now okay to reassert requests without controlling host bandwidth. 5.4 types of service requests the categories of service requests that a CD1865 can generate are explained below. each channel ? s transmitter, receiver, and modem pins require service from the host occasionally; however, each category of service request conditions can tolerate different latencies in being serviced. conditions for service requests fall into three basic categories: data is received from the remote device and needs to be transferred to the host. figure 6. internal fair-share operation r s q external request (i/o pin) internal request ok to assert to CD1865 internal request logic latch
CD1865 ? intelligent eight-channel communications controller 32 datasheet data from the host can be given to the transmitter fifo, which is now empty. a modem signal changes state. three separate service request levels are provided to support the following three categories: 5.4.1 receive service requests the receive service request is unique because it has two subtypes; that is, it is capable of returning one of the two different vectors during a service request acknowledge cycle. the two sub-types are ? ? receive good data ? and ? receive exception ? . the reason there are two types within one category of service request is that, while good data and exceptions require different handling, they are both of equal priority, and need to be serviced in the order they are received. for example, suppose two good characters are received, then an exception character, and then another good character is received. there must be a service request for the first 2 bytes of good data, then for the exception, and then for more good data. if exception service request is at a different level, the exception character is processed either before or after the good data, and not in sequence as it should be. this method also allows the receive good data-handling routine in the host to be very fast and efficient, since it only has to move ? n ? bytes to a buffer. all special-case conditions can be put in a separate handler, where they do not slow down normal data transfers. exception characters are characters with errors or that match the defined special characters, line breaks, and certain time-out conditions. data must not be read from the receive fifo or the receive status fifo except when the CD1865 is within the context of a receive data service request. 5.4.1.1 receive good data ? a receive good data service request is asserted for any of the following three conditions: 1. rxfifo threshold reached, and the fifo contains good data. 2. rxfifo threshold not reached, but the fifo contains good data, and the receive data timer times-out. 3. rxfifo threshold not reached, but the fifo contains good data, and the newly arrived data contains an exception condition. when any of these conditions occur, the modified service request vector indicates to the host that the service request is for good data. the CD1865 continues to add bytes to the fifo, and it increments the count register for each good byte added, and this allows for optimally efficient use of the fifo. it is not necessary to accept any or all of the good data that is available when a good data interrupt is received. if a host buffer is too full to accept 8 bytes, a smaller number (even 0) can be read, the service request context left, and the host buffer handled first. the CD1865 again generates another good data service request when any of the three conditions listed above are met. source pin name request match register name receive data * transmit data * modem signal change *
intelligent eight-channel communications controller ? CD1865 datasheet 33 if the condition that caused the request in the first place remains true, the CD1865 quickly generates another service request. if no data is read, this is always the case. if some, but not all, of the available data is read, conditions 1 and 2 are not true, but condition 3 may be true if an exception condition is the cause of the good data interrupt. if this becomes a problem, one solution is to temporarily disable receiving interrupts on that channel. to avoid fifo overflow, do not disable the channel for very long. 5.4.1.2 receive exception unusual or exception conditions are reported to the host one character at a time through the receive exception service request. as with normal receive processing, the host determines the requesting channel by reading the gcr. it can then determine the specific exception(s) by reading the receive character status register. exception conditions are generated for parity errors, framing errors, fifo overrun, special character recognition, break detect, and for a special feature called the ? no new data timer ? (nndt). nndt is a receive timer option to generate a service request for the first receive data time-out following the transfer of all data from the fifo to the host. it is often useful, when managing relatively large i/o buffers, for an i/o processor to determine that ? no data has arrived lately ? . this event is used to transfer the contents of the local buffer that has been storing data from the CD1865 fifo for host-system processing. this service request is a receive exception sub-type, and can be used to signal that it is time to transfer the buffer. this feature can be enabled or disabled by controlling the nndt bit in the service request enable register. as shown in figure 7 , every time a received character is loaded into the fifo, the timer is restarted. if the timer times-out, the CD1865 checks if there is any data in the fifo. if there is, a good data service request is posted to avoid ? stale data ? . if there is no data in the fifo, the CD1865 checks that nndt is enabled and ? armed ? . arming occurs when the last character is transferred out of the fifo to the host. if nndt is on and armed, a receive exception service request is posted to inform the host of this event. note that the nndt is not armed if the last character removed from the fifo is an exception character. every receive exception is a unique, one-character event. the receive data count register has no meaning, unlike the receive good data case, the status byte in the receive exception handling routine must be read. the receive data count register and the associated data character is discarded by the CD1865 at the end of the service routine. the status byte must be read before reading the data byte. once the data register is read, the status byte is no longer available.
CD1865 ? intelligent eight-channel communications controller 34 datasheet figure 7. receive timer operation put character in fifo; reload timer timer = 0 ? is fifo empty ? post receive good data service request no new data timeout feature enabled ? post receive exception service request n y n y background scanning detects new character arrived resume background scanning loop... ...from other background processing... resume background scanning loop... nndt internal flag ?armed? ? clear nndt internal flag y y n n
intelligent eight-channel communications controller ? CD1865 datasheet 35 5.4.2 transmit service requests each transmitter contains 8 bytes of transmit fifo in addition to the transmit holding register and the transmit shift register. as data is being transmitted, the fifo status is being monitored by the CD1865. a service request is invoked for one of the following conditions: transmit fifo empty ? when the transmit fifo is empty, there is still one character in the transmit holding register and one character in the transmit shift register. the host has two character times to respond to this request without causing a gap in the transmit data stream. transmitter empty ? the transmit fifo, transmit holding register, and the transmit shift registers are now empty. this signifies that all characters written to the fifo are completely transmitted. the host can select which one of these causes a transmit service request, and it is used by programming the options in the service request enable register (srer). data must not be put into the transmit fifo at any time other than when the CD1865 is in a transmit service request context for that channel. during a transmit service, characters (up to eight) are placed into the fifo by the transmit data register (tdr). 5.4.3 modem signal change service requests the CD1865 can be programmed to assert a service request when a channel ? s modem input signals has changed states. the change-detect options are programmed in the modem change option registers. individual modem pin service requests are enabled by setting the corresponding bits in the service request enable register. the host must read the modem change register during a modem change service to determine which modem signal changes were detected. this is indicated by a ? 1 ? in the appropriate bit location. the modem change register must be reset to a ? 0 ? by the host before exiting the service request because the CD1865 does not do this. refer to section 7.4 for more details. 5.4.3.1 using modem pins as input/output the pins labelled as modem pins are general-purpose i/o pins that can be controlled by either the CD1865 processor or the host system. there is no direct, hardwired connection from any modem pin directly to a transmitter or a receiver. this means that these pins can be used for general- purpose i/o if they are not needed for modem-control purposes. see section 7.4 for more details. 5.5 implementing service requests the CD1865 is designed to easily interface with any processor, yet be efficient and flexible enough to provide maximum throughput. the CD1865 generates service requests and waits for acknowledgments of these from the host. however, service requests can be implemented in either hardware or software; likewise, acknowledgments can be affected either way to offer maximum advantages to the system designer and programmer. this interfacing can be grouped as various steps. service requests must be ? noticed ? by the host system before they can be acted on, and this can be done the following three ways:
CD1865 ? intelligent eight-channel communications controller 36 datasheet 1. provide three levels of interrupt support, with three separate levels and three separate vectors. this is well-suited to motorola ? 680x0 processors. 2. provide a single level of interrupt support; this is an effective method when using 8-bit processors such as the z-80 and many intel ? microprocessors. 3. poll the device directly in software. once the host has ? noticed ? the service request, it has the following two choices for acknowledging the request and beginning to service it: acknowledge the request by a hardware-based service acknowledgment, as is typically done in interrupt-driven systems. acknowledge the request in software by reading from a register in the CD1865. thus, there are six theoretically possible options for interfacing the CD1865 to the host system. two of the methods (2a and 3a) are not practical to implement without external hardware, and offer no performance advantage. each of the other four methods has advantages and drawbacks depending on the type of host cpu being used and whether or not that host cpu supports more than one CD1865. the four methods used are listed in table 4 . this method is called ? full interrupt ? type a ? . the system is fully interrupt driven with acknowledgments in hardware. it requires a host with at least three interrupt priority levels available and the ability to acknowledge on multiple levels. this is the technique used by motorola 680x0 processors. it is the most efficient method when the host cpu has a relatively fast interrupt context switch time and when the host cpu has duties other than driving the CD1865s. this method is called ? full interrupt ? type b ? . it still has three levels of interrupt, but provides a single acknowledgment level. it is commonly used in intel-type processor systems where there is an 8259a interrupt controller. the 8259a receives the three levels of interrupt, but it provides its own vector to the host rather than that of the CD1865s. then the host acknowledges the CD1865s service request by reading the vector register. this method is called ? single interrupt ? , and is best-suited to systems having only a single interrupt input, such as most 8-bit microprocessors. after the host receives its interrupt and is entering its interrupt service routine, it reads the CD1865 to evaluate which of the three types of service requests is responsible for the interrupt.then it acknowledges the interrupt by reading the appropriate request acknowledge register. note that the single interrupt signal must be generated by the logical or of the three request outputs with external output gates, not by ? wire-or ? ing ? them. table 4. service request methods how the host detects the service request 1. three-level hardware interrupt 2. single-level hardware interrupt 3. software polling how the host acknowledges the interrupt a. hardware-based service acknowledge 1a full interrupt ? type a 2a not recommended (inefficient) 3a not recommended (inefficient) b. software-based service acknowledge 1b full interrupt ? type b 2b single interrupt 3b software polled
intelligent eight-channel communications controller ? CD1865 datasheet 37 this method is called ? software polled ? . polling is often used in situations where the host system is primarily dedicated to servicing the serial channels and has few other tasks to perform. it is usually better when the host cpu has a long interrupt context switch time. in this method, the host periodically checks the CD1865s to determine if any service requests are pending. if they are, the host acknowledges them in software and proceeds with the service. one of the advantages of the CD1865 is that it allows the use of any of the above techniques, or a combination. such a combination is referred to as ? mixed-mode operation ? . in a typical mixed- mode design, normal interrupts are used to signal to the host that service is required. after the host enters its interrupt service routine, it services the CD1865 that generated the service request. then the host polls the CD1865s to determine if more channels require service. if the host finds a channel requiring service, it handles it in the usual manner, and then proceeds to poll for more service requests. this process continues until all CD1865s are handled. because the host is not exiting and re-entering its own interrupt context each time, much host cpu time is saved, resulting in even faster overall performance. the advantage of a mixed-mode design is that the software has complete control of whether to be fully interrupt driven or to poll in certain circumstances. a mixed-mode design is recommended to tune a system for optimum performance. a CD1865 evaluation board can be employed to analyze CD1865 performance and evaluate different software implementations. intel testing (in an at-compatible ? 386 machine) found that a mixed-mode system provided the highest overall throughput with minimum host cpu loading. this is generally found to be the case with host processors that have relatively long interrupt response times, such as the intel ? 386. 5.5.1 method 1a ? full interrupt ? type a, three-level interrupt with three-level acknowledge this method is illustrated in figure 8 . it is best-suited for 680x0-family processors. the three CD1865 service request lines are connected to the interrupt priority encoder. when the host performs an interrupt acknowledgment cycle, the CD1865 responds with its vector. the host uses this vector to jump directly to the appropriate service routine. other methods can also be used with a 680x0-based system.
CD1865 ? intelligent eight-channel communications controller 38 datasheet 5.5.2 method 1b ? full interrupt ? type b, three-level interrupt with single-level acknowledge this method is illustrated in figure 9 . it is useful with 80x86 systems that use the 8259a interrupt controller. since the 8259a supplies its own vector to the host when an inta cycle occurs, the host can simply read the CD1865 ? s vector by the method described in the polled interface example or a separate device select decode can be provided to drive the ackin* input. after the 8259a supplies a vector to the 80x86 host cpu, the host performs a software acknowledgment to the CD1865, and transfers the CD1865 vector to the host. this allows the service request to be processed. figure 8. three-level interrupt with three-level acknowledge example eight-level priority encoder CD1865 # 2 CD1865 # 1 m68000 microprocessor address decode logic a1 ? a3 a8 ? a23 a4 ? a7 d0 ? d7 as* ipl1 ipl2 ipl3 a0 ? a2 a3 ? a6 cs* d0 ? d7 rreq* treq* mreq* a0 ? a2 a3 ? a6 cs* d0 ? d7 rreq* treq* mreq* ackin* ackout* ackout* ackin*
intelligent eight-channel communications controller ? CD1865 datasheet 39 5.5.3 method 2b ? interrupt interface, single-level interrupt with single-level acknowledge this method is illustrated in figure 10 . it is best-suited to host systems having a single interrupt input. the three service request lines from the CD1865 are run through an ? or ? gate to the host ? s interrupt input. when an interrupt occurs, the host system polls the CD1865s, determines which of the three levels is interrupted, and acknowledges it accordingly. figure 9. three-level interrupt with single-level acknowledge example interrupt controller (8259a or equivalent) CD1865 # 1 CD1865 # 2 microprocessor address decode logic a1 ? a3 a8 ? a23 a4 ? a7 d0 ? d7 ale int a0 ? a2 a3-a6 cs* d0 ? d7 rreq* treq* mreq* a0 ? a2 a3 ? a6 cs* d0 ? d7 rreq* treq* mreq* ackin* ackout* ackout* ackin*
CD1865 ? intelligent eight-channel communications controller 40 datasheet 5.5.4 method 3b ? polled interface this method is illustrated in figure 11 . polled operation can be used with any type of host cpu, or it can be used in combination with interrupts to provide a mixed-mode system optimized for a particular application. in a polled system, the host reads the service request status register (srsr) within the CD1865 to determine whether there are any channels that need service. (note that unlike traditional uarts, only one register needs to be read to determine if there are any channels in any device that need attention, and this saves time). if the host finds channels needing service, it acknowledges the required type by reading one of the three request acknowledge registers. these provide a vector that can be used to jump directly to the correct service routine. processing from this point proceeds as in the case of interrupt-driven operation. note that the difference between this method and method 2b lies in how the host system becomes aware of the need to service the CD1865. in method 2b a single interrupt starts the process. in method 3b the host polls periodically. the two methods can be combined ? an interrupt triggers the first service, but the host continues to poll until any other pending requests are serviced. figure 10. single-level interrupt with single-level acknowledge example CD1865 # 1 CD1865 # 2 microprocessor address decode logic a1 ? a3 a8 ? a23 a4 ? a7 d0 ? d7 ale int a0 ? a2 a3 ? a6 cs* d0-d7 rreq* treq* mreq* a0 ? a2 a3 ? a6 cs* d0 ? d7 rreq* treq* mreq* ackin* ackout* ackout* ackin* or
intelligent eight-channel communications controller ? CD1865 datasheet 41 there is a difference between the CD1865 and conventional dumb uarts that makes the CD1865 more efficient even when operating in a polled environment. with a dumb uart, the host polls each channel in turn to determine whether it has any data. with the CD1865, the host polls the CD1865s as a group for whether it has data. if it does, the CD1865s indicates the channel, rather than the host testing each channel in turn. in fact, it is not possible for the host to dictate which channel is serviced; the CD1865 determines this order. this minimizes both the number of polling steps required and the amount of time each needs. this also ensures fair, balanced service of all channels. there are several ways that a host system can poll the CD1865. each method has certain advantages. the most direct method is to read the service request status register (srsr). this register contains three bits that indicate whether there is a request pending for receive, transmit, or modem signal change, on the CD1865 being read. there are three more bits that provide the same information for all CD1865s in the system ? these three bits reflect the state of the wire-or ? ed external request lines. thus a single read operation can determine if there is any activity. figure 11. simple software polled interface example CD1865 #2 CD1865 #1 microprocessor a1 ? a3 a4 ? a7 d0 ? d7 a0 ? a2 a3 ? a6 a0 ? a2 a3 ? a6 d0 ? d7 d0 ? d7 rreq* treq* mreq* rreq* treq* mreq* ackin* ackout* ackout* ackin*
CD1865 ? intelligent eight-channel communications controller 42 datasheet 5.5.5 comparison of interrupt and polled code sequences figure 12 and figure 13 show the code sequences for polled and interrupt service request methods. figure 12. polled code sequence read service request status from srsr receive request pending? transmit request pending? modem signal change request pending? n n read requesting channel number read number of bytes from rdcr set up host ? s buffer pointers set loop counter = rdcr read rdr write data to pointer location increment pointer decrement loop counter if loop counter = 0 save pointer exit isr read rrar to acknowledge, get status vector good data ? y y y to transmit routine to modem routine n handle ? bad ? data y n
intelligent eight-channel communications controller ? CD1865 datasheet 43 5.5.6 cascading service requests with multiple CD1865s regardless of the method used to support service requests, multiple CD1865s can be cascaded by tying together all * lines, all * lines, and * lines. these lines are open-drain so they may be wire- or ? ed. the CD1865s are then daisy chained by simply connecting the ackout* of one device to the ackin* of the next. the host knows which CD1865 is requesting service by the id value returned through the global interrupt vector register. up to 32 CD1865s can be cascaded in any one daisy chain in this manner. since multiple daisy chains are possible, the maximum number of CD1865s can be large. the 32- per-daisy-chain limit is set by the five bits in the gvr. these bits can be used to identify which CD1865 responded to the service request acknowledge cycle. the user must program different values into the upper-five bits of each CD1865s gvr. figure 13. interrupt code sequence interrupt occurs read requesting channel number read number of bytes from rdcr set up host ? s buffer pointers set loop counter = rdcr read rdr write data to pointer location increment pointer decrement loop counter if loop counter = 0 save pointer exit isr entry point for good data interrupt service routine n y
CD1865 ? intelligent eight-channel communications controller 44 datasheet note that thirty-two CD1865s is the logical limit per daisy chain. since it takes over 1000 ns for an acknowledgment to ripple down 32 devices, it may not be efficient to have one long chain in heavy-traffic applications. note: in some systems that daisy chain many CD1865 devices, a potential timing hazard exists if the host processor does not allow sufficient time for the removal of the ackin*/ackout* daisy-chain signal to propagate through all devices. in the event that the host processor begins i/o operations with another section of logic and applies ds* (rd* or wr* in an intel environment) while an active ackin* is being applied to a CD1865 due to propagation delay time, unpredictable results can occur. this constitutes an illegal acknowledge cycle. the failure mode is most often a cessation of service requests from the device, especially of the type that is being serviced when the illegal access occurs. take care to ensure that the 35-ns propagation delay per device is included in any wait-state generation. 5.5.7 multiple CD1865s without cascading it is possible to interface several CD1865s without using the cascade feature. there is an advantage to this because as there is less delay incurred while waiting for the service acknowledgment to ripple down a chain of devices. there are two possible disadvantages. if each of the CD1865 ? s three service request lines has a separate input to the interrupt controller, the interrupt controller is more complex, and the fair-share feature does not work. if the service request lines are wire- or ? ed, fair share works, but the host has to test each CD1865 in turn to see which one generated the service request. to implement this method, simply connect the CD1865 address and data lines in the usual manner. 5.5.8 acknowledging service requests as mentioned in section 5.5 on page 35 , two different methods are used to acknowledge a service request. one method is hardware-based, and the other is software-based. the hardware-based mechanism is a specific type of bus cycle that uses the ackin* and ackout* signals and the in the CD1865. an acknowledge cycle is defined where ackin* and ds* are active and cs* is inactive. this method is used by processors that perform interrupt acknowledge cycles, such as the 680x0. the software-based mechanism uses three registers ? receive request acknowledge register, transmit request acknowledge register, and modem request acknowledge register. reading any of these registers has the effect of acknowledging a service request, and the data read is the appropriate vector, that is, the contents of the global interrupt request vector register. the low- three bits of this register are modified to indicate the specific type of interrupt being acknowledged. if the host reads these registers when no service request is pending, either of two things can happen. if daisy chaining of acknowledgments is enabled, the ackout* pin of the CD1865 asserts. if daisy chaining is not enabled, the part supplies a vector with the low-three bits set to a ? 0 ? . thus, it is possible to ? fish ? for service requests, that is, to acknowledge each CD1865 in turn until a non-zero vector is received. ? fishing ? is not usually an efficient software technique, but can be useful in some circumstances. for example, in systems that are normally interrupt-driven, but where interrupts are not available for diagnostics or other reasons, the host can determine if a service request is pending by reading the appropriate request acknowledge register. the CD1865 must be configured not to daisy chain; in this case it returns a vector if a request is pending, or ? 00 ? if no request is pending. the host can try all three levels of request in turn. this method works for either single CD1865s or multiple
intelligent eight-channel communications controller ? CD1865 datasheet 45 devices. in multiple-device systems, either disable daisy chaining on all devices and ? fish ? each individually, or disable daisy chaining on the last device only and ? fish ? the device at the beginning of the chain. both methods of acknowledging service requests can be used interchangeably. it is usually advantageous to use mixed mode. for example, after receiving an interrupt and servicing it in the normal manner, the host should read the service request status register (srsr) to see if other requests are pending. if so, the host can acknowledge by reading the appropriate request acknowledge register (rrar, trar, and mrar) and proceed to service the request. this avoids the time required for the host to exit its interrupt routine, only to re-enter it immediately for the next request.
CD1865 ? intelligent eight-channel communications controller 46 datasheet 6.0 system bus interface and system clock figure 14. internal block diagram cpu rom ram i/o pins (modem control) transmit service request queue receive service request queue modem service request queue bus interface service request logic rts* cts* dtr* dsr* cd* 5 lines 5 lines 5 lines 5 lines 5 lines 5 lines 5 lines cs* ds* r/w dtack* intel/mot* reset* clk dblclk no_osc osc1 osc2 adr[0 ? 6] data[1 ? 7] rxdata txdata rreq* treq* mreq* ackout* ackin* per channel timer receive bit transmit bit dual-baud rate generators interrupt handler engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine receive bit transmit bit dual-baud rate generators engine engine rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata rxdata txdata
intelligent eight-channel communications controller ? CD1865 datasheet 47 6.1 system interface considerations when using the CD1865, two areas where system architects, designers, and programmers should consider options are system clock speed, and unclocked versus clocked-host bus interface. 6.2 system clock and bit rate options 6.2.1 system clock system clock is a high-frequency clock (supplied by the user) used by the CD1865 to receive all the necessary timing. the CD1865 is capable of handling system clock levels of ttl-compatible voltage swings; however, the v il and v ih specifications are not identical to all families of ttl logic. specifically, the clock signal (and the reset signal) have lower v il and higher v ih than the worst-case specifications of some ttl families. in general, any ttl family is adequate if not heavily loaded. refer to the dc specifications in section 10.3 for details. the CD1865 can be operated from the main system clock or its own clock. operation from the main system clock can reduce the number of clocks required, and it allows the bus interface between the system and the CD1865 to be clocked, but in general, typical system clock speeds are not exact baud-rate multiples. as bit rates are received from the clock, it is important to consider this when selecting a clock value. if exact baud rates are needed, or the system clock is not a convenient value, the CD1865 must be supplied with its own clock or crystal. 6.2.2 external clock it is recommended that the 2 -clock option (oscillator or crystal) be used wherever possible. figure 15 shows a possible design configuration for the clock circuitry if the crystal is being used. please refer to the CD1865 evaluation kit documentation for details on the design configurations used. the crystal used for the evaluation board is a 66-mhz third overtone part. figure 15. 2 clock option osc 2 osc 1 200k ? 500k 33 pf 33 pf
CD1865 ? intelligent eight-channel communications controller 48 datasheet 6.2.3 1 clock option it is recommended that a 2 -clock option be used where ever possible. if using a 1 -clock options, refer to table 10 on page 129 for clock duty cycle requirements. 6.2.4 bit rate options the CD1865 supports independent transmitter and receiver bit rates on each of its eight channels. the bit rate is determined by a 16-bit period value (divisor) stored in the transmitter bit rate period registers (tbprh and tbprl), or in the receiver bit rate period registers (rbprh and rbprl). these registers establish the period of the corresponding transmitter and receiver bit rate counters. to set a given bit rate, the value to be loaded is determined by the following equation: this equation may yield a non-integer result. the nearest integer value is the optimum choice for that bit rate and system clock combination. the value loaded in the bit rate period registers must be that integer expressed as a 16-bit binary value. if rounding is necessary, the percentage bit rate error can be calculated by: the popular bit rates and their corresponding divisors at various system clock rates are shown in table 5 . figure 16. no_osc osc1 osc2 dblclk clk ckout d q rq from reset logic bit rate divisor clk frequency {in hertz} () (16 x desired bit rate {in bits per second}) ---------------------------------------------------------------------------------------------------------- - = bit rate divisor ? integer () 100 bit rate divisor ?
intelligent eight-channel communications controller ? CD1865 datasheet 49 table 5. bit rate constants, clk = 33 mhz bit rate divisor ? error 110 493e 0.000% 150 35b6 0.000% 300 1adb 0.000% 600 d6e 0.015% 1200 6b7 0.015% 2400 35b 0.044% 4800 1ae 0.073% 9600 d7 0.073% 19200 6b 0.393% 38400 36 0.538% 56000 25 0.461% 57600 24 0.538% 64000 20 0.703% 76000 1b 0.509% 115200 12 0.538% ? all divisor values are in hex. table 6. bit rate constants, clk = 25 mhz bit rate divisor ? error 110 377d 0.003% 150 28b1 0.003% 300 1458 0.006% 600 a2c 0.006% 1200 516 0.006% 2400 28b 0.006% 4800 146 0.147% 9600 a3 0.147% 19200 51 0.467% 38400 29 0.762% 56000 1c 0.352% 57600 1b 0.467% 64000 18 1.696% 76000 15 2.144% 115200 e 3.219% ? all divisor values are in hex.
CD1865 ? intelligent eight-channel communications controller 50 datasheet table 7. bit rate constants, clk = 20 mhz bit rate divisor ? error 110 2c64 0.003% 150 208d 0.004% 300 1047 0.008% 600 823 0.016% 1200 412 0.032% 2400 209 0.032% 4800 104 0.160% 9600 82 0.160% 19200 41 0.160% 38400 21 1.376% 56000 16 1.440% 57600 16 1.376% 64000 14 2.400% 76000 10 2.720% 115200 b 1.376% ? all divisor values are in hex. table 8. bit rate constants, clk = 15 mhz bit rate divisor ? error 110 214b 0.003% 150 186a 0.000% 300 c35 0.000% 600 61a 0.032% 1200 30d 0.032% 2400 187 0.096% 4800 c3 0.160% 9600 62 0.352% 19200 31 0.352% 38400 18 1.696% 56000 11 1.547% 57600 10 1.696% 64000 f 2.400% 76000 c 2.720% 115200 8 1.696% ? all divisor values are in hex.
intelligent eight-channel communications controller ? CD1865 datasheet 51 6.2.5 maximum throughput limits the CD1865 is internally a fully static, synchronous design. consequently, the maximum data rate handled by CD1865 is determined by the clock speed at which it is operating. there are a fixed number of CD1865 processor cycles required to process each bit and character; a slower CD1865 processor rate equates to a slower bit rate. the minimum clock frequency required can be determined by the data rate needed for support. in general, the CD1865 can maintain 100% full-duplex throughput when divisors of 16 or greater are used. for a given master clock frequency, this limitation can be used to determine the maximum bit rate at which the system can sustain 100% throughput on both receive and transmit. divisors as small as 12 can be used, however a degradation in throughput is observed. this degradation is seen as gaps between transmit characters and are, in effect, extra long stop bits. this is a fail-safe condition. divisors smaller than 12 can work in an application if less than eight channels are enabled. 6.3 CD1865 basic bus interface and addressing the CD1865 is addressed through an active-low chip select (cs*) in conjunction with seven address inputs a[0:6] that are mapped CD1865 internal addresses in two addressing modes ? global and channel. in channel addressing mode, the bits defining the channel to be accessed are provided from the channel access register (car) within the CD1865. the most-significant address input (a6) performs the selection between global- and channel- specific addresses. if this bit is a ? 1 ? , the address is global, and is not associated with any specific channel. if this bit is a ? 0 ? , the address is channel-related. with the exception of the fifos, all channel-specific registers are accessed by first setting the required channel number in the low-three bits of the channel access register. fifos can only be accessed within the context of a service routine. attempting to force access to a particular fifo by setting the car causes unpredictable and incorrect results. within the context of a service request, the effective channel access value is automatically controlled by the CD1865, thus the car should not be modified by the host system during service-request processing. the advantage of this method is that the host never performs any address computation to access the CD1865 during service requests. because only the registers specific for the active channel (that is, the one being serviced) are accessible to the host within a service request routine. an automatic indexing feature handles this, thus avoiding any burden on the host. refer to section 9.3 on indexed indirect registers for details. 6.3.1 intel ? versus motorola ? interface signals and addressing the CD1865 supports two bus handshake methods. one is patterned after the motorola 680x0- family processors, and the other after intel 80x86-bus interfaces. bus interface selection is achieved by the intel/mot* signal. when this signal is ? high ? , the intel bus interface is selected, and when this signal is ? low ? , the motorola bus interface is selected. this selection affects the logical meaning of two pins, but has no effect on bus timing. the two signals having dual meaning are rd* versus ds*, and wr* versus r/w*. when the intel bus interface is selected, these two pins function as rd* and wr*. these pins can be connected to either the ior* and iow*, or to memrd* and memwr* depending whether the CD1865 is
CD1865 ? intelligent eight-channel communications controller 52 datasheet mapped into memory or i/o space. these pins then serve to select the CD1865, and when either is active (along with cs* or ackin*) the CD1865 considers itself selected. cs* and ackin* must never be active at the same time. when the motorola bus interface is selected, these two signals function as ds* and r/w*. ds* must be asserted (along with cs* or ackin*) for all types of cycles, and r/w* should be low when writing to the device. in either case, the choice of bus interface is entirely up to the user. this feature is for user convenience, and to accommodate the address and bus-control logic that are used. the CD1865 has an 8-bit data bus, and it is a common practice (when connecting 8-bit peripherals to 16- or 32-bit systems) to connect them to only one lane, or 1-byte position. thus, the CD1865 registers only appear in the host ? s address space at every other byte address. the most common practice is to connect the CD1865 to the portion of the data bus labelled d0 ? d7. for the little-endian processors, such as intel ? s, the CD1865 appears at even addresses (a0 = 0). for big-endian processors, such as motorola ? s, the CD1865 appears at odd addresses. 6.3.2 unclocked versus clocked bus interface depending on the type and speed of the host processor, another important choice is determining whether the system bus interface will be clocked or unclocked with the host cpu clock. because there is a single clock for both the bus interface and bit-rate generation, the decision to use either clocked or unclocked bus interface is affected by whether exact bit rates are required. most applications do not require exact bit rates, and operate with rates varying by one percent or so. if exact bit rates are required, the clock speed must be a baud-rate multiple. one method of bus interfacing may be preferable to another in certain applications. although the easiest way to interface to the CD1865 is by using the unclocked handshake supplied by dtack*, in some cases it may be better to design a clocked interface. the latter is true if the host system is running at the same clock speed (or a multiple) of the CD1865 speed. unclocked bus interface an unclocked bus interface is the easiest interface to implement. simply connect the address, data, and control lines in the customary manner, and use dtack* to control the number of wait states either by connecting it to the processor ? s dtack* (if it has one), or by feeding into a wait-state generator. figure 17 on page 53 shows a typical unclocked bus interface. the maximum bus cycle time is two clock periods plus 10 ns, though typically less because this specification is based on worst-case internal synchronization delays. using dtack* saves time; however, it is permissible to hard-wire the wait-state generator for the maximum time. clocked bus interface the CD1865 bus interface is controlled by a state machine that samples on the falling edge of the clock. external strobes (cs*, ds*, and r/w*; or cs*, and rd* or wr*) that meet the setup time requirement cause a bus cycle to begin. the external interface can be designed to meet these setup time requirements, and to have shorter CD1865 access cycles. figure 18 on page 54 shows a typical clocked bus interface.
intelligent eight-channel communications controller ? CD1865 datasheet 53 a bus cycle consists of two half-clock periods. during the clock-low period, the transaction is set up internally, and the local bus arbitration occurs. during the clock-high period, the read or write transaction to ram occurs. on write cycles, the data from the host is latched internally on the low- to-high clock transition. on read cycles, the data is available shortly after the end of the clock-high period. read and write cycles differ slightly in timing; during a write, it is permissible to remove the wr* or ds* relatively early during the high-clock period, however, this cannot be done during read cycles. the rd* or ds* strobe is used as an output enable, and must remain low for the data to appear on the external data bus. service request acknowledgment cycles follow a different timing than ordinary read cycles. first, it is necessary to have the address stable before asserting ackin*. second, the setup time from ackin* and ds* (or rd*) going low to the falling clock edge is longer due to additional internal logic involved in service request acknowledge cycles. figure 17. typical unclocked bus interface a[0:6] r/w* cs*, ds* db[0:7] dtack*
CD1865 ? intelligent eight-channel communications controller 54 datasheet 6.4 interface examples there are some general design considerations when interfacing the CD1865 to any host environment. the three service request pins (*, *, and *) can change at any time, and this can introduce metastability problems if the interrupt controller requires clocked signals. when designing, take care that all signals are stable when needed. the service request pin of the type being acknowledged is negated at the end of the service acknowledgment bus cycle. often, during the course of servicing one channel, another channel reaches a state where a request would assert, for example, while servicing receive on channel one, channel two ? s fifo fills. the service request bits in the service request status register (srsr) does not reassert until approximately two clock periods after the host completes its write to the end of register (). in polled or mixed-mode systems, to determine whether another service request of the same level is pending, and to make sure that the host does not re-read the srsr too quickly, insert a no-operation (or similar) instruction. performing an ? invalid ? service acknowledgment bus cycle on the CD1865 is permissible, but it can cause problems in certain circumstances. an invalid service acknowledgment is an acknowledgment for which there is no request pending. if a service request acknowledgment bus cycle is performed by the host when no service request is pending, either of two things can occur. if the value on the address bus matches one of the three values in the three service match registers (), and daisy chaining is enabled, the CD1865 assumes that another device down the daisy chain should receive the request, and asserts its ackout* pin. this propagates down the CD1865 chain until eventually the last CD1865 asserts its ackout*. figure 18. typical clocked bus interface new cycle may begin don ? t care valid don ? t care don ? t care cd1864 ds* cs* r/w* address undefined valid data-read dtack* clock
intelligent eight-channel communications controller ? CD1865 datasheet 55 at this point, the system waits endlessly unless the bus cycle terminates. the best method is to connect the ackout* of the last CD1865 in the chain to a bus-error input on the host. if there are multiple CD1865s that are not cascaded, the ackout* signals should be or ? ed together through a gate or a pal. if an acknowledgment occurs and the value on the address bus does not match any of the match registers, the first CD1865 in the chain does not pass it along or assert dtack* and the system waits endlessly unless there is a bus time-out or other mechanism to detect this condition. in either of these circumstances, the ? value ? on the data bus is likely to be ffh because the bus is floating (this is system dependent). to make a robust design, do not use ffh as a valid global service vector register (gsvr) value. if daisy chaining is not enabled, then the CD1865 returns a vector of ? 00 ? for invalid acknowledgments. 6.4.1 interfacing to 80x86-family processors the intel 80x86 family processors often use the 8259a as the interrupt controller, which supplies its own vector during the inta cycle. the easiest way to interface the CD1865 to an intel processor is by mixed mode, as described in section 5.5 . there is one ? bug ? in the 8259a to be aware of. the 8259a can change the prioritizing of its eight inputs, which can result in one of its acknowledge outputs going low briefly (~30 ns) if an input changes at a certain time. this typically occurs if a higher-priority input to the 8259a asserts when the 8259a is about to issue an acknowledge to a lower-priority device. if this occurs at the beginning of a cycle, this brief pulse can cause the CD1865 (and other devices) to malfunction. be sure that this does not occur. see intel 8259a data sheet for details. 6.4.2 interfacing to 680x0-family processors the 68000-family interface is quite straightforward. the three service request lines go through a priority encoder to the 680x0 ipl inputs. the CD1865s ackin* pin is driven by a decoder. when the 680x0 performs an interrupt acknowledge cycle, it drives its address lines a1, a2, and a3 with a three-bit value indicating the level being serviced. the other address lines are set to a 1. if the level being serviced corresponds to a level assigned to the CD1865, external decoding logic should assert the CD1865 ackin* pin. the value on address lines a0 to a7 is programmed into the , so the CD1865 recognizes the acknowledgment and proceeds as described in the service request section 5.3.1 . all CD1865 service requests can also be routed to a single interrupt level by using a mixed-mode interface, as described in section 5.5 . 6.4.3 interfacing to the vme bus the CD1865 can be directly interfaced to the vme bus, and only requires a small amount of logic to complete the interface. this is necessary because service request acknowledgment works differently on the vme bus than on the CD1865. vme defines seven levels of interrupts; each level can be shared among multiple vme cards. during an interrupt acknowledge cycle, the vme bus provides three bits on the address bus, indicating the level being acknowledged (a1-a3). each vme card must pass along an interrupt on all levels it is not using but the CD1865 does not automatically pass an interrupt acknowledgment.
CD1865 ? intelligent eight-channel communications controller 56 datasheet to recognize how this difference can cause a problem, suppose that the three service request lines from the CD1865 are connected to levels 7, 6, and 5 of the vme bus (see figure 19 on page 56 ). also, attach a 74xx244 so that during an interrupt acknowledgment cycle provides an 8-bit code consisting of the three address bits plus five more hard-wired bits to the CD1865. now, whenever an acknowledgment of a level 5, 6, or 7 interrupt occurs, the CD1865 either responds or passes the acknowledgment properly. if an acknowledgment occurs on levels 1 ? 4, the daisy chain ? breaks ? because the CD1865 does not recognize a match. this condition can be easily rectified, as shown in figure 20 on page 57 . a pal is used to assert ackout* whenever ackin* occurs on a level not being used by the CD1865. the pal is programmed for fixed levels. for example, if the current vme bus interrupt level is 1 ? 4, the pal asserts ackout* whenever ackin* is active. if the current level is 5 ? 7, the pal asserts ackout* when ackout* from the CD1865 is active. if required, the assignment of vme interrupt levels to the CD1865 can be field-programmable by supplying additional inputs to the pal, indicating the levels being used by the CD1865. figure 19. incorrect vme interface CD1865 a0 ? a6 rreq* treq* mreq* ackout* ackin* 74xx244 arbitrary value a1 ? a3 irq7* irq6* irq5* ackin* ackout* a1 ? a7 vme bus (buffers not shown) iack*
intelligent eight-channel communications controller ? CD1865 datasheet 57 figure 20. correct vme interface CD1865 a0 ? a6 rreq* treq* mreq* ackout* ackin* pal 74xx244 arbitrary value a1 ? a3 irq7* irq6* irq5* irq4* irq3* irq2* irq1* ackin* ackout* a1 ? a7 vme bus (buffers not shown)
CD1865 ? intelligent eight-channel communications controller 58 datasheet 7.0 serial interfaces 7.1 receiver operation 7.1.1 basic operation all receivers are disabled upon master reset. to prepare a receiver, first initialize and then enable it. once initialized and enabled, the receiver monitors the rxd line and waits for a high-to-low transition, which indicates a start bit. this sampling is performed at one-eighth of the system- clock rate regardless of the programmed bit rate, and it provides accuracy of synchronization with the incoming data. see figure 21 below for CD1865 bit synchronization. once a transition is detected, the receiver checks the rxd input state again (a half-bit time later) to validate that it is a start bit. a valid start bit is defined a ? space ? or a logic ? 0 ? . if the rxd input is no longer a ? space ? , then a false start bit is assumed and the receiver resumes the search for a high-to-low transition. if a valid start bit is detected, the rxd input is sampled at one-bit time intervals in the middle of the bit to ensure stable data. characters are assembled according to the programmed content of the channel option register (cor1). valid character framing (presence of a stop bit), and optional parity bits are checked. after a character is assembled, it is placed in a temporary holding register. then the CD1865 processor checks for error conditions, fifo overrun, and special character match before placing the character and its corresponding status into the receive and status fifos. 7.1.2 receive fifo operation eight bytes of fifo are assigned to each receiver for data storage, in addition to the receive holding register and the receive shift register. once the number of data bytes received and stored in the fifo reaches a programmed threshold, the CD1865 can be programmed to generate a service request. see figure 22 on page 59 for receive operation. the receive fifo service request threshold can be selected by programming the rxth bits 3:0 in the channel option register 3. a service request threshold of one-to-eight characters can be selected. once this threshold is defined, a service request is automatically triggered when the condition is met. it is possible that by the time the host responds to the service request, there is more data in the fifo than the threshold level. figure 21. bit synchronization in CD1865 1/2-bit time start bit detect samples at 1/8-system clock full-bit time full-bit time full-bit time full-bit time full-bit time full-bit time full-bit time full-bit time full-bit time
intelligent eight-channel communications controller ? CD1865 datasheet 59 an overrun condition occurs when the new data arrives, but the receive fifo and the receive holding register are both full. the new data is lost and the overrun indication is flagged on the character in the holding register. that character and its status including the overrun indication is eventually transferred to the host by a receive exception service request. note that this character is good, and is the last character received before the overrun occurred. receiver service requests are enabled or disabled by the receive data bit in the enable register (). receive data bit, when set to a ? 1 ? , enables service requests to be asserted for the above causes. the prescaler period counter is a 16-bit counter clocked by the system clock. if the system clock is a 33-mhz clock, the maximum count establishes a clock tick every 1.9859 ms. the prescaler period should be set to generate a minimum tick period of 1.0 ms. the receive time-out counter is an 8-bit counter decremental on every tick of the prescaler period counter. at the maximum count per tick, the maximum time-out period is 0.506 seconds. the receive time-out is always enabled to transfer data when the receive data service request is enabled. from the system applications view-point, this time-out function is important for asynchronous data transmission. this is especially true when a fifo is in use and a service request threshold for the fifo is set greater than one character. the timer service request eliminates long response times when excessive delay between characters occurs caused either by the remote operator or due to the line being disabled. the ? no new data ? timer service request, which occurs after all data is transferred to the host, may be used to manage transfers from the host ? s receive data buffers. figure 22. receive operation receiver shift register receiver holding register full/ empty bit receiver receive data count register background code: h.r.-to-fifo transfer, flow control, other features foreground code: bit assembly, s.r.-to-h.r. transfer (interrupt-driven) (polling loop) dtr out dsr in receive status fifo receiver fifo
CD1865 ? intelligent eight-channel communications controller 60 datasheet 7.1.3 fifo timer operations the CD1865 uses the receive fifo timer for two purposes. the first is to avoid ? stuck ? (or ? stale ? ) data in the fifo caused by not receiving enough characters to trip the threshold, which causes a service request to be issued. the second is to signal the host that there has been a relatively long pause in received data. it is useful for the host to know that ? no data has arrived lately ? when managing relatively large i/o buffers. this event flushes the buffer up to the host for processing. to avoid ? stuck ? data, each time the CD1865 moves a character into a channel ? s receive fifo, it sets the channel ? s receive fifo timer to the value contained in the channel ? s receive time-out period register (rtpr). if the timer expires before new data arrives, a receive good data sub-type service request is asserted for the channel if the receive data enable bit in the is set. the other receive timer option is to generate a service request for the first receive data time-out following the transfer of all data from the channel to the host. this is called the no new data time-out (nndt). this service request is a receive exception sub-type with a status type of ? time-out exception ? . there is no data character associated with the time-out exception status. this option can be enabled or disabled by controlling the nndt bit in the . if enough data arrives to fill the receive fifo to the level set by the rxth bits in cor3, or if a special character arrives in the receive fifo and the rxsc bit of is set, the channel asserts the receive data service request without waiting for the timer to expire. if the timer times-out and the fifo is not empty, the ? stale data ? condition has occurred, and the device posts a receive good data interrupt. if the timer times-out and there is no data, two conditions are checked. first, a test is made to see if the feature is enabled, if it is true, then another flag is tested to make sure this is the first time the condition has occurred. if this is true, a receive exception service request is posted. (the nndt internal flag is armed when the fifo is emptied). 7.1.4 receive service requests the receive service request is unique as it has two sub-types; that is, it is capable of returning one of two different vectors during a service request acknowledge cycle. the two sub-types are receive good data and receive exception. the reason there are two types within one category of service request is because while good data and exceptions require different handling, they are both of equal priority and need to be serviced in the order they were received. suppose, for example, two good characters are received, then an erroneous character, then another good character, then there must be a service request for the first 2 bytes of good data, then for the exception, and then for more good data. if exception service requests were at a different level, the erroneous character would be processed either before or after the good data, and not in normal sequence. receiver service requests are invoked under several conditions. conditions that cause a receive good data service request are: receive fifo threshold reached or exceeded receive fifo time-out ? interval between character receptions exceeds time-out value conditions that cause a receive exception service request are: receive erroneous data (parity error) framing error (no stop bit) no data received time-out (optional)
intelligent eight-channel communications controller ? CD1865 datasheet 61 special character detection break detect note: data cannot be read from the receive fifo or the receive status fifo except when the CD1865 is within the context of a receive data service request for a specific channel. 7.1.5 receive good data ? service request a receive good data service request is asserted for any of the following three conditions: 1. receive fifo threshold reached, and the fifo contains good data. 2. receive fifo threshold not reached, but the fifo contains good data and the receive data timer times-out. 3. receive fifo threshold not reached, but the fifo contains good data and the newly arrived data contains an exception condition. when any of these conditions occur, the modified service request vector indicates to the host that the service request is for good data. it is not necessary to take all or any of the available good data when a good data service request is received. if a host buffer is too full to accept 8 bytes, a smaller number (even a ? 0 ? ) can be read. service request context is then left, and the host buffer is dealt with first. the CD1865 generates another good data service request when any of the three conditions listed above are met. the CD1865 immediately generates another service request if the condition that caused it in the first place remains true. if no data is read, this is always the case. if some, but not all of the available data is read, conditions 1 and 2 are not true; but condition 3 may be true if an exception condition caused the good data service request. if this is a problem, one solution is to temporarily disable receive service requests on that channel. to avoid fifo overflow, do not delay handling the channel for too long. 7.1.6 receive exception service request unusual or exception conditions are reported to the host one character at a time through the receive exception service request. as with normal receive processing, the host determines the requesting channel by reading the gcr. it can then determine the specific exception(s) by reading the receive character status register before performing the appropriate action. receive exceptions are always 1-byte deep; multiple bytes of exception conditions causes multiple receive exception service requests. for many exceptions, it is not necessary to read the receive data register after the receive status register is read. for example, if special character detection is enabled, and the service request is for recognition of a special character, the character is known by definition because the exception code indicates the detected character or character sequence. however, for every exception a byte is placed in the data fifo, even though the contents of that byte may be suspect data, and the byte is discarded at the end of the exception service routine regardless of whether it was read by the host or not. this is done to keep the status and data fifos in lock-step with each other. this is different in the case of a receive good data service request where the user is free to read as many or as few bytes as required.
CD1865 ? intelligent eight-channel communications controller 62 datasheet regardless of the number or type of exceptions occurring, they are reported to the host one character at a time; that is, the number-of-bytes value in the receive data count register is not meaningful. since every error is reported individually, there is no receive time-out exception generated if the only characters in the fifos are error or exception characters. 7.1.7 types of errors there are four types of errors recognized by the CD1865: parity, framing, line break, and overrun. if parity checking is enabled, parity errors are logged in the status fifo and the suspect data is placed in the receive data fifo. an error is also logged for framing, that is, absence of a stop bit. in these cases, the suspect character is in the receive data fifo and the appropriate status byte is placed in the status fifo. when a line-break condition is recognized (zero data with zero parity, and no stop bit), one null (00) character is loaded into the receive fifo, and a break status is recorded in the status fifo. note that if odd parity is set and the bits received are all zeroes, it is marked as both a break character and a parity error. generally when a break character is received, pre-set parity error can be ignored. no further fifo entries are made until normal-character reception is resumed, for example, a start bit is found. the line must go high and then back to low for this to occur. multiple errors in 1 byte are possible because the CD1865 evaluates the characters bit-by-bit as it receives them. for example, a parity error is detected and flagged before the CD1865 recognizes that a framing error has occurred. parity plus framing or parity plus break error can occur, but framing plus a break error cannot occur because, if a character is received with every bit equal to a ? 0 ? , it is marked as a break character. if some bits are a ? 1 ? , but the stop bit is missing, for example, a ? 0 ? , it is marked as a framing error. thus, any one character cannot have both framing and break errors. the length of the stop bit is not checked by CD1865. any stop bit long enough to be sampled in mid-bit time as a ? 1 ? is interpreted as a valid stop bit. in addition to all of the other errors, if an overrun occurs, the overrun error bit is set along with other error bits. 7.1.8 types of exceptions 7.1.8.1 special character recognition ? special character recognition ? is a feature found only on the CD1865 and other intel data communications controllers. the on-chip processor compares every good character received with user-defined special characters stored in registers on the device. both single-character and two- character sequence recognition is possible. this capability has several applications, including in- band flow control. special-character matches are reported to the host by a receive exception service request. four special character registers are provided per channel, allowing received characters to be compared to as many as four special characters. however, these four registers are shared between receive special character detection and the send special character command, so some planning is required for using these characters. the full set of features and options available as part of special character recognition allows for xon/xoff flow-control to be implemented transparently to the host, and at the same time, detect either of two other special characters in the data stream and alert the host of their arrival.
intelligent eight-channel communications controller ? CD1865 datasheet 63 the user may individually enable any CD1865 channel to recognize special characters. there are six bits used to control the various recognition and flow-control modes. the following four registers are used to control character recognition: the following table shows the effects of xonch and xoffch: note: the two-character pairs can share a common first character; however, the same character must be programmed in both schr1 and schr2. single- versus double-character recognition is controlled by xonch and xoffch. if single- character compare is enabled, the CD1865 compares data in the data stream against the four special characters stored in the special character registers (schr1-4). if fewer than four special characters are required, the unused special character register(s) should be disabled by duplicating the pattern to be matched in the unneeded register. when reporting a special character, the CD1865 always reports the lowest-number special character register that matches. to set up special character recognition, first set the characters to be matched in registers schr1- 4, then set xonch and xoffch according to the length of match wanted. set the scde bit, and lastly enable service requests by setting rxsc. special characters are reported to the host by placing the appropriate status word in the status fifo and the recognized special character in the receive data fifo. in the case of a two-character sequence, only the second character is stored in the receive fifo. this is because there is room only for one character and preserving both is not needed as these characters are user-defined. 7.1.9 flow-control characters automatic in-band flow control of the CD1865 transmitter is a subset of the special character recognition capability, so to understand both these features is important. refer to section 7.2 on page 68 for transmitter operation. flow-control characters and operation are programmable on a per-channel basis. this is important to operating systems that allow users to configure their own terminal settings independently. bit name register function scde cor3 enables detection of special characters. must be set for in-band flow control to work. rxsc enables generation of service requests. cannot be overridden by other bits. does not need to be set for in-band flow control to work. xonch cor3 controls single- versus double-character matching. xoffch cor3 controls single- versus double-character matching. xonch xoffch characters matched 0 0 match on: any of schr1 ? 4 0 1 match on: schr1 or schr3 or (schr2 and schr4) 1 0 match on: (schr1 and schr3) or schr2 or schr4 1 1 match on: (schr1 and schr3) or (schr2 and schr4)
CD1865 ? intelligent eight-channel communications controller 64 datasheet because the CD1865 performs flow-control functions before the data is passed to the host, the response time required of the host to avoid data overrun is greatly reduced. additionally, the flow- control characters can be stripped from the data stream, relieving the host from processing them. to use automatic flow-control, the special character detection (scde) must be enabled by bit 4 of channel option register 3 (cor3). this causes all error-free received data to be compared for a match with the special character registers (schr1 ? 4). in addition, flow-control must be enabled by transmit in-band enable (txibe, bit 6) of cor2. this causes the special characters to be interpreted as flow-control characters. for single-character flow-control sequences, schr1 is used as xon and schr2 as xoff. schr3 ? 4 are available for use as normal special-detect characters. if two-character sequences are enabled by xoffch and xonch (bits 6 and 7) of cor3, schr1 and schr3 form the xon sequence, and schr2 and schr4 form the xoff sequence. if flow-control characters are passed to the host, they are marked as special characters 1 or 2 in the receive channel status register (rcsr). if a two-character sequence is detected, it is compressed to the second character and a status indicating a match of the first character is set. a valid two- character sequence requires that both characters be received without error; if an error occurs on the second character the first character is treated as a normal character, and this does not affect non- flow control special character detection.
intelligent eight-channel communications controller ? CD1865 datasheet 65 bits affecting flow control are summarized below. the fct bit controls whether flow-control characters are passed on to the host. it has meaning only when in-band flow control is enabled, that is, txibe is set. when the CD1865 receives a flow- control character or character sequence and fct is a ? 0 ? , it starts or stops the transmitter, as required, and passes the character onto the host as a receive exception. since there is a one-to-one correspondence between the status and receive fifo, the flow-control character detected is stored in the receive fifo, and a status byte indicating special-character detect is stored in the status fifo. if fct is a ? 0 ? , rxsc must be set to enable service requests to be issued to the host. otherwise, flow-control characters cannot be passed as receive exceptions and is instead passed as good data. if the fct bit is a ? 1 ? , the CD1865 still starts or stops the transmitter, as required, but the character(s) are discarded, and no exception is posted. in either case, the flow-control status of the transmitter (on or off) is maintained by the CD1865 in the channel control status register (ccsr). the fct bit makes it possible to support ? escaping ? of flow-control characters. some systems follow a convention where two identical flow-control characters in a row indicates that flow control is not to be performed, but rather one flow-control character is to be kept in the normal received-data stream, and the other ? escape ? character is to be discarded. if the CD1865 is in such a system, set the fct bit to a ? 0 ? , allowing flow-control characters to pass onto the host. when the host detects two flow-control characters in a row, it simply restores the proper flow-control state of the channel and discards one of the characters. however, for most systems the fct bit can be set to a ? 1 ? , reducing loading on the host. 7.1.9.1 no new data received time-out it is sometimes useful for the host to sense that ? no data has arrived lately ? , when managing relatively large i/o buffers. this event is used to flush the buffer up to the host for processing. one of the receive timer options, no new data time-out (nndt), generates a service request for the first receive data time-out following the transfer of all data from the channel to the host. this service request is a receive exception sub-type, and can be enabled or disabled by controlling the nndt bit in the . refer to figure 23 on page 67 for the timer logic. the timer is started only on data arrival. if the CD1865 processor determines that the receive fifo is empty, the timer has expired, and there is a previous receipt of good data (and the timer feature is enabled), a receive exception occurs with a status indicating that a time-out has occurred. if the last receive exception service request was triggered by a time-out (to avoid ? stale ? data) the no new data time-out service request occurs immediately after the data transfer service request completes. if the last service request was triggered by reaching the threshold, the timer bit name register function scde cor3 enables special character recognition. txibe cor2 enables automatic transmitter flow-control. fct cor3 sets transparency mode of flow-control. xonch xoffch xon xoff 0 0 schr1 schr2 0 1 schr1 (schr2 and schr4) 1 0 (schr1 and schr3) schr2 1 1 (schr1 and schr3) (schr3 and schr4)
CD1865 ? intelligent eight-channel communications controller 66 datasheet still has to expire so that some time passes before the no new data service request occurs. likewise, if the last service request was triggered by some other error, such as parity, the timer still has to expire so that some time passes before the no new data service request occurs. the no new data function should not be confused with the time-out that occurs when there is good data in the fifo but the threshold has not been reached and the timer expires. this event is a receive good data service request, and not a receive exception event. timing-out to transfer good data before it becomes ? stale ? is standard, and it cannot be turned off by the user.
intelligent eight-channel communications controller ? CD1865 datasheet 67 figure 23. no new data timer logic put character in fifo; reload timer timer = 0 ? is fifo empty ? post receive good data service request no new data timeout feature enabled ? post receive exception service request n y n y background scanning detects new character arrived resume background scanning loop... ...from other background processing... resume background scanning loop... nndt internal flag ? armed ? ? clear nndt internal flag y y n n
CD1865 ? intelligent eight-channel communications controller 68 datasheet 7.1.10 programming notes if a special condition (for example, framing or a parity error) occurred on a special character, the CD1865 does not interpret this character as matched. flow-control characters that are processed and discarded because fct is set never cause an overrun. special character recognition only occurs on characters that have no other problems or errors. there is one case where the CD1865 does not find a special character even though the character has been correctly received. if a good character arrives as the ninth character (for example, the fifo is full), it stays in a holding register. if another character arrives, the good character in the holding register has its status marked as ? overflow ? , indicating that it is the last good character received; however, it is not recognized as a special character. there are two cases where the CD1865 might not detect a two-character sequence. if the first character has been found, but no other character has been received for a long period of time and the receive time-out event occurs, no match is found because the first character is flushed up to the host. if special-character detection is disabled by clearing scde just when the CD1865 has received the first two-character special-character sequence, but has not received the second character yet, the first character is lost. 7.2 transmitter operation 7.2.1 basic operation refer to figure 24 on page 69 for a diagram of transmitter operation. upon power-on reset, all transmitters are disabled with their transmit output held in the ? mark ? or a logic ? 1 ? condition. other channel parameters are undefined. the minimum configuration of a channel for transmission consists of specifying the bit rate, parity, and number of stop bits. in-band and out-of-band flow control should also be set as required. next, set either (or both) of the service request enable bits. then issue the transmit enable command and either of two service request enable bits. for normal operation, set the txrdy bit. this causes a service request to be issued when the fifo is empty. since on power-up the fifo is empty, a service request is received (less than 1 ms.), and at that time data can be transferred to the fifo. data can not be transferred to the fifo as part of channel initialization; instead one has to be in the service-request routine to do this. refer to the section 5.3 for details. once the channel is initialized and serviced, and a character is written into the transmit fifo, the transmitter starts to transmit by first sending the start bit (space or a logic ? 0 ? ) followed by the data character according to predefined character length, least significant bit first. an optional parity bit (none, odd, even, or forced) is appended followed by the final stop bit (a logic ? 1 ? or a ? mark ? ). the length of the stop bit can be one, one-and-a-half, two, or two-and-a-half bit-times long. the transmitter continues sending characters one after the other until the transmit fifo is empty. when the transmit fifo is empty and the last character is sent, the transmitter stops transmission and holds the txd output in the ? mark ? (1) condition. transmission resumes another character is in the fifo. in some cases it must be determined if the channel is completely done transmitting the last bit of the last character ? for instance, before changing the bit rate. in such a case, the service request is to be issued only when the last character is sent, rather than when the fifo is empty. in this case, instead of setting the txrdy bit, set the txmpty bit. this causes a service request to be issued only when the transmitter is completely empty.
intelligent eight-channel communications controller ? CD1865 datasheet 69 for details on transmitter flow-control operation, refer to the section 7.3 on page 72 . 7.2.2 fifo operation an 8-byte fifo is provided for each transmit channel. in addition to the 8-byte fifo, the CD1865 also contains a transmit holding register and the transmit shift register for each channel. however, when servicing a transmit service request, only up to eight characters can be written into the transmit data register (tdr) consecutively. 7.2.3 transmit service requests generating a transmit service request depends on control bits in the enable register (). setting the txrdy bit of the specifies that a transmit service request be generated when the fifo is empty. when this condition occurs, there is still one character in the transmit holding register and another character in the transmit shift register. the host cpu, therefore, has up to two-character times to respond before the transmitter output goes into the idle (mark) condition. setting the txmpty bit instead of the txrdy bit of the specifies that a transmit service request be generated only when the fifo, the transmit holding register, and the transmit shift register are empty. when this condition occurs, it means that all characters are completely transmitted and the channel can now be re-configured. it is recommended that one of the two bits be set as needed, but do not set both bits at the same time. end of a service request must be signalled to the CD1865 by writing to the end of register (). figure 24. transmitter operation full / empty bit transmitter holding register tranmsitter shift register transmitter fifo background code: fifo-to-h.r. transfer, flow control, other features foreground code: bit disassembly, h.r.-to-s.r. transfer (polling loop) (interrupt-driven) rts out cts in
CD1865 ? intelligent eight-channel communications controller 70 datasheet 7.2.4 special transmitter commands the CD1865 is capable of sending special characters preemptively (bypassing the fifo): sending break characters and inserting delays or pauses either between characters or to lengthen a break. there are two basic mechanisms the CD1865 uses for these ? send special character ? and ? embedded transmit command ? functions. 7.2.5 special character transmission by send special character command selected special characters, or two-character sequences, may be transmitted preemptively by setting the appropriate bits in the channel command register (ccr). the send special character (send sp ch) bit of the ccr, when set, initiates the send special character command. sspc0 ? 2 bits of the ccr then specify which character or two-character sequence is used. the choice of a single- or two-character sequence is determined by the xonch and xoffch bits of cor3. when a send special character command is given, the CD1865 inserts the special character(s) into the data stream immediately following the current character in the transmit holding register. thus, it is ensured that the special character begins transmitting within two-character times after the command is issued. the send special character command overrides all other flow-control modes, including the state of txen and cts*. generally this is the preferred case. however, sample cts* or cd* in some applications to determine if it is okay to send a character before invoking the send special character command. the ccr is reset by the CD1865 as an acknowledgment of the command. a new command must not be issued if the ccr contents are non-zero. a send special character command is recognized and cleared within 125 s (at 15 mhz, proportionally longer at lower clock speeds), unless a break is being sent. if a break is being sent, the special character is not sent until after the break time is complete. 7.2.6 embedded transmit commands the CD1865 may be enabled to recognize certain ? escape ? sequences as commands embedded in the transmit data stream. these commands are issued to introduce a time delay between characters, to insert an idle period during the transmission, or to send a break on the line. these capabilities are enabled on a per-channel basis by setting the embedded transmit command (etc) bit in the channel option register 2 (cor2). the ? null ? (00) character is used as the controlling character to initiate the special action. to preserve data transparency, two mechanisms are provided to allow the null character to be sent as data. if the host must transmit a null character as data, either the etc mode may be disabled, or the null character may be preceded by a null, that is, ? 00 00 ? causes one-null character to be sent. if the etc bit is not set, the ? 00 ? character has no effect, and it may be sent as ordinary data. etc mode may be enabled or disabled ? on-the-fly ? . the CD1865 uses the transmit timer to generate time delays between characters in the output data stream. it is also used to extend the duration of a line-break transmit condition when the delay is inserted between the ? start break ? and ? stop break ? embedded-transmit commands. all of the timers count ticks are determined by the prescaler counter. the two eight-bit prescaler period registers (pprh and pprl) determine the real-time length of a tick. a tick is the period of the CD1865 system clock input (clk) multiplied by the period registers ? contents.
intelligent eight-channel communications controller ? CD1865 datasheet 71 7.2.7 sending breaks line breaks may be sent by embedding the following sequences in the data stream (all values are given in hex): 00 81 send break: enter line-break condition for at least one character time. the line enters the break condition and stay there until one of the following conditions is met: 1. another character needs to be sent. 2. if the insert delay special character sequence immediately follows the send break sequence, the duration of the break transmission is extended by the amount of the programmed delay. the insert delay sequence is: 00 82 xx. this inserts a delay of ? xx ? (interpreted as an unsigned binary number) times the programmed timer ? tick ? set by the prescaler period registers. multiple insert delay commands can be executed consecutively by the CD1865 to allow delays of arbitrarily long length. if ? xx ? is a zero, no delay is inserted. 3. the stop break sequence ? 00 83 ? is encountered next. this sequence is optional, and exists to provide a way to terminate a break without actually sending another character. if another character is being sent anyway, no stop break is required. if there is no more data to be sent, the txd pin remains in the state it was left in by the last character. since the stop bit is always a ? 1 ? , the line is left in the idle state after any character, except for the break character. the break character leaves the line in the ? 0 ? state until more data needs to be sent. long breaks can be sent by simply sending one break and then waiting. to terminate the break, send the stop break sequence or send another character. sending long breaks has precedence over the send special character command, for example, the time delay duration must pass before the special character is sent. 7.2.8 sending inter-character delays in some applications it is desirable to pause between characters. for example, certain types of electro-mechanical teletype equipment cannot handle characters continuously at their specified bit rate. to accommodate this, the CD1865 allows insertion of a delay between characters. the user embeds an escape sequence into the output data stream to generate delays between characters. when the CD1865 encounters the insert delay escape sequence, it sets the transmit timer to the value contained in the escape sequence. when the timer expires, the CD1865 loads the next character into the transmit shift register and resumes output (unless the next character begins another escape sequence). the escape sequence for an inserted delay consists of three characters: ? 00 ? , ? 82 ? , and ? tt ? . the time-out value ? tt ? is expressed in timer ticks. 7.2.9 summary of special transmitter commands the etc bit in cor2 must be set to enable the following functions: char. sequence effect 00 00 send one-null character
CD1865 ? intelligent eight-channel communications controller 72 datasheet 7.3 flow control variations in response times and system data transfer rates between systems communicating across asynchronous interfaces give rise to a need to control the flow of data between them. systems typically are implemented with a receive buffer for temporary storage of data. when this buffer is nearly full, the receiving computer ? flow-controls ? the remote transmitter. when, after processing the existing data, more buffer space is available for the receive process, the receiving computer signals the remote to resume transmission. flow control is implemented in one of two ways ? ? out-of-band ? or ? in-band ? signaling. out-of- band signaling is a hardware-based mechanism, performed by extra wires such as the rts/cts and dsr/dtr pairs. it has the advantage of complete independence from the data stream. however, it is not always possible to provide all of the wires necessary to support out-of-band flow control. also standards for implementing out-of-band flow control vary widely. in-band flow control works by inserting special flow-control characters into the stream of data being sent. it has the advantage that only the data circuit is required, thus only two wires are needed. the disadvantage of in-band flow control is that the two communicating computers must perform additional functions, specifically, they must monitor the data stream for flow-control characters and take the appropriate action. this can be quite burdensome because the host computer that receives a flow-control command must recognize this event quickly and respond in a timely manner to avoid overrun at the remote receiver. although there are advantages and disadvantages to each system, in general the trend is toward in- band flow control. this is because it is more useful than out-of-band flow control over a wider range of applications, such as communication by modems. the CD1865 provides significant performance advantages over conventional solutions during both the receive processing of and the transmission of flow-control characters. it does this by handling almost all flow control automatically, without host intervention. it also provides tools to make host intervention, when required, much easier. because the CD1865 performs flow-control functions automatically, before the data is passed to the host, the response time required of the host is substantially reduced. the possibility of data overrun is also reduced. additionally, the flow- control characters themselves can be stripped from the data stream, relieving the host from processing them. the flow-control status of the transmitter is always available to the host as a bit in the channel control status register (ccsr). 7.3.1 receiver flow control the CD1865 provides both in-band (xon/xoff) and out-of-band flow control functions for ensuring that the receiver does not overflow. in-band flow control is semi-automatic and helps the host manage its buffer size. out-of-band flow control is fully automatic and can be used to prevent the CD1865 receive fifo from overflowing. figure 25 on page 73 diagrams the receiver flow-control logic. 00 81h send one-character time of line break 00 82h xxh delay for ? xx ? prescaler time ticks (for example, transmit timer value is ? xx ? ) 00 83h stop break char. sequence effect
intelligent eight-channel communications controller ? CD1865 datasheet 73 when the CD1865 receiver is too busy, the transmitter can be used to send xoff/xon to the remote device. this receiver software (in-band) flow control is covered in section 7.3.3 on page 74 . the CD1865 transmitter can be controlled by the remote device. this transmitter software (in- band) flow control is covered in section 7.3.6 on page 76 . the current flow-control status is always available to the host. it is stored in the channel control status register (ccsr). two bits, receive flow-on and receive flow-off, show whether the last flow-control command sent by the CD1865 was on or off. as long as the receiver is enabled, the CD1865 continues to receive any data sent regardless of whether it has requested the remote to shut off. 7.3.2 receiver hardware (out-of-band) flow control out-of-band flow control uses the modem handshake signal (dtr*) to control the flow of data. whenever the receive fifo reaches a user-defined threshold, dtr* is negated. this event can be used to signal the remote to stop sending characters. the threshold is set by four bits in the modem control option register 1, and can be any level from one to eight, or disabled. the dtr* pin is also negated whenever dtr* mode is set and the channel is disabled or reset. if dtr* mode is not set, the dtr* pin is not changed by the CD1865, and remains at whatever value the host sets it to. while it is possible to set the dtr* threshold lower than the service request threshold, the part operates as though the dtr* threshold was the same as the service request threshold. if the dtr* threshold is set lower, it is ignored, and dtr* negates when the service request threshold is reached. if required, set the dtr* threshold to a ? 1 ? , and then it ? tracks ? the other threshold automatically. figure 25. receiver flow-control logic receiver shift register receiver holding register full/ empty bit receiver fifo, status fifo background code: h.r.-to-fifo transfer, other features. flow control: foreground code: bit assembly, s.r.-to-h.r. transfer (interrupt-driven) (polling loop) dtr out dsr in match special character? dsr* asserted? dtr* threshold reached?
CD1865 ? intelligent eight-channel communications controller 74 datasheet the receiver monitors the state of dsr* (if enabled) and ignores data on the receive data pin if dsr* is negated. this feature is controlled by the dsrae bit, bit 0 of channel option register 2 (cor2). 7.3.3 receiver software (in-band) flow control host receive buffers often cannot keep pace with data being received. the CD1865 transmitter can be used to send flow-control characters to the remote device. this avoids over-flowing the receive buffers in the host. however, transmitting flow-control characters is an additional complication and source of delay when using conventional devices. as the host ? s receive buffer becomes full, the transmit process must be flagged to insert a flow-control character (or sequence) in the transmit data stream. any data already in the transmit fifo is transmitted ahead of the flow-control character, increasing the response time at the remote end. with the CD1865, in-band flow control of the remote system is semi-automatic; two commands (send xon, send xoff) can be issued by the host whenever the host wants to flow-control the remote. these special commands make host programming and buffer management easier because it allows the flow-control character(s) to be sent as the next character, regardless of the contents of the transmit fifo or host transmit buffers. flow-control characters are transmitted by the send special character command in the channel control register (ccr). the lower-three bits in the command determine which of the four-special characters are to be sent. if two-character flow control sequences are enabled, requesting either schr1 or schr2 causes the appropriate two-character sequence to be transmitted. refer to section 7.2.5 on page 70 for special character definition details. special characters are transmitted regardless of the state of transmit enable or transmit flow control. transmitting flow- control characters can be handled independently of the current state of the transmit channel. in sending special characters, the CD1865 bypasses any data already in the transmit fifo, thereby minimizing delay in transmitting flow-control characters. the maximum delay is two-character times. however, if a break is currently being transmitted, the CD1865 waits for the break transmission to terminate before the special character is transmitted, regardless of the length of the break. the CD1865 keeps a copy of the current state of the receive flow in the ccsr. two bits are used to indicate the current state of the channel regarding flow control: rxfloff and rxflon. rxfloff and rxflon are meaningful only when the CD1865 is flow-controlling the remote. whenever an xoff is transmitted, rxflon is cleared and rxfloff is set. when a subsequent xon is transmitted, rxfloff is cleared and rxflon is set. when data is received from the remote, rxflon is cleared. the ? 00 ? state is provided as an aid to the programmer in determining whether there might be a problem in a communications link. if rxflon remains set during normal operation, it could indicate that the remote did not correctly receive the last xon. if flow-control characters are sent by the host by embedding them in the transmit fifo rather than using the send special character function, the CD1865 flow-control logic does not sense them, and the ccsr is not affected. the table below summarizes the meaning of rxfloff and rxflon.
intelligent eight-channel communications controller ? CD1865 datasheet 75 7.3.4 transmitter flow control the CD1865 provides both automatic in-band (xon/xoff) and out-of-band flow control functions. in-band flow control recognizes special characters or character sequences for xon and xoff control embedded in the data stream. out-of-band flow control uses the modem handshake signals, rts/cts, to control the flow of data. both types of flow control are implemented between the transmit fifo and the transmit holding register, not between the transmit holding register and the transmit shift register. figure 26 on page 76 diagrams the transmitter flow-control logic. all automatic flow-control functions are controlled by bits in channel option register 2 (cor2), except dtr threshold, which is controlled by modem change option register 1 (mcor1). channel enable and flow-control status is stored in the channel control status register (ccsr). a txen bit shows the enabled status of the channel ? s transmitter. two bits, txfloff and txflon, are used to indicate the current state of the channels ? flow control. once the automatic flow-control modes are invoked by the host, all actions are transparent to the host. if receipt of flow-control characters by the host is not required, the flow-control transparency bit of cor3 may be set to not pass received flow-control characters onto the host. if txibe is set, the CD1865 implements the flow-control function on the transmitter regardless of the fct mode. the host can review the status of the channel by reading the channel control status register. if flow-control status is needed by the host, the scde and rxsc control bits must be set and the fct bit must not be set. a special character detect status and the special character is presented to the host by a receive exception service request. if the host wishes to manually flow-control the transmitter, it can do so by using the txen bit, which stops transmission after the current character completes. rxfloff rxflon meaning 1 1 illegal mode. 1 0 xoff is last flow-control character sent (flow off). 01 xon is last flow-control character sent (flow on). 0 0 flow is on, data has been received.
CD1865 ? intelligent eight-channel communications controller 76 datasheet 7.3.5 transmitter hardware (out-of-band) flow control transmit out-of-band flow control is performed automatically by the CD1865 by the cts* pin, if the cts auto enable (ctsae) mode is enabled in bit 1 of cor2. in this mode, before a character from the fifo is transmitted, the cts* pin is tested, and, if inactive, transmission is delayed. since flow control is implemented between the fifo and the transmit holding register, when cts* is negated, it is possible to get both the current character being sent and the character in the transmit holding register. however, the send special character command (that is, xon and xoff) overrides cts* inactive. this is generally preferred; however, in some applications sample cts* or cd* before sending a special character. to complete the handshake with a remote device, an rts automatic output (rtsao, bit 2) mode is also provided. this causes the rts pin to be asserted throughout any data transmission: normal, break, and special characters. the rts pin is activated whenever there is data in the fifo and transmitter registers. it is held active until after the last stop bit of the last character is transmitted. 7.3.6 transmitter software (in-band) flow control the CD1865 transmitter can be programmed to respond automatically to flow-control characters received by the receiver. this feature requires no host assistance and substantially reduces host processing requirements. if this automatic mode is enabled, when the remote unit transmits an xoff character to the CD1865 (to prompt the CD1865 to suspend transmission), the CD1865 terminates the transmission. the CD1865 may require approximately 500 microseconds (~2 character-times at 38.4 kbps) after receipt of the stop bit to recognize that the character it has figure 26. transmitter flow-control logic full/ empty bit transmitter holding register tranmsitter shift register transmitter fifo background code: fifo-to-h.r. transfer, flow control, other features foreground code: bit disassembly, h.r.-to-s.r. transfer (polling loop) (interrupt-driven) rts out cts in
intelligent eight-channel communications controller ? CD1865 datasheet 77 received is a flow-control character and set its internal flag to stop transmission. transmission actually stops as soon as the characters in the transmit shift register and transmit holding register are shifted out. to enable in-band flow control, two bits must be set. first, the special character detection (scde) must be enabled by bit 4 of channel option register 3 (cor3). this causes all error-free received data to be compared for a match with the special character registers (schr1 ? 4). second, flow control is enabled by transmit in-band enable (txibe, bit 6) of cor2, the special characters are interpreted as flow-control characters. different flow-control protocols use either single- or two-character sequences for the xon and xoff functions. for single-character flow-control sequences schr1 is used as xon, schr2 as xoff, and schr3-4 as normal special detect characters. if two-character sequences are enabled, by xoffch and xonch (bits 6 and 7) of cor3, schr1 and schr3 form the xon sequence and schr2 and schr4 form the xoff sequence. many operating systems allow users to define their own terminal ? s flow-control settings independently. the CD1865 allows flow-control characters to be programmed on a per-channel basis. the fct bit controls whether flow-control characters are passed on to the host. when the CD1865 receives a flow-control character or character sequence and fct is a ? 0 ? , it starts or stops the transmitter as required, and passes the character on to the host as a receive exception service request. since there is a one-to-one correspondence between the status fifo and the receive data fifo, the flow-control character detected is stored in the receive data fifo, and a status byte, indicating special character detect, is stored in the status fifo. if the fct bit is a ? 1 ? , the CD1865 still starts or stops the transmitter as required, but the character is discarded, and no exception is posted. in either case, the flow-control status of the transmitter (on or off) is maintained by the CD1865 in the channel control status register (ccsr). if flow-control characters are passed to the host, they are marked as special characters 1 or 2 in the receive channel status register (rcsr). if a two-character sequence is detected, it is compressed to the second character and a status indicating a match of the first character is set. a valid two- character sequence requires that both characters be received without error. if an error occurs on the second character, the first character is treated as a normal character, and the second character is reported as an error by a receive exception service request. bits affecting flow control are summarized in the table below: bit name register function scde cor3 enables special character recognition. txibe cor2 enables automatic-transmitter flow control. fct cor3 sets transparency mode of flow control. ixm cor2 sets implied xon mode xonch xoffch xon xoff 0 0 schr1 schr2 0 1 schr1 (schr2 and schr4) 1 0 (schr1 and schr3) schr2 1 1 (schr1 and schr3) (schr2 and schr4)
CD1865 ? intelligent eight-channel communications controller 78 datasheet the remote device can signal the CD1865 to resume transmission in one of two ways depending on the setting of the implied xon mode (ixm) option bit cor2. when the ixm bit is set, the CD1865 resumes transmission upon receipt of any character, for example, each character is an implied xon. in implied xon mode it is assumed that if the remote is capable of transmitting data, it is able to receive as well. if a character is treated as an implied xon, no special status is recorded in the rcsr, and the txflon bit is not set in the ccsr. an implied xon character is not stripped if flow- control transparency is enabled. when the ixm bit is not set, the CD1865 only resumes transmission upon receipt of an xon character. in addition, the host may force a resumption of transmission by issuing a transmit enable command, which clears the txfloff bit. the xon and xoff characters or character sequences are equal in a toggle mode. there is no special bit to enable this mode. the CD1865 detects this mode whenever the xon character equals the xoff character, and it implements toggle mode automatically. in toggle mode, whenever the special character is received, the current state of flow control is toggled. if flow control transparency is set, the character is dropped. if not in flow-control transparency, the character is passed to the host. if it is a single character, the special character status is ? 1 ? and the character is put in the receive data fifo. in two-character sequence, the second character is placed in the receive data fifo along with special character ? 1 ? in the status fifo. the txfloff and txflon bits indicate channel status when the remote device is flow-controlling the CD1865 transmitter. when the remote requests the CD1865 to stop transmission, the CD1865 sets the txfloff status bit in the ccsr. if txfloff is set, the last flow-control character received was a flow-off. when the remote sends an explicit flow-on character, the CD1865 clears the txfloff bit, and set the txflon bit. (if flow is resumed because of implied xon, txfloff is cleared, but txflon is not set). when the CD1865 resumes transmission, the txflon bit is cleared. transmit flow status bits is also cleared by enabling or disabling the transmitter or resetting the channel. this is summarized in the table below: 7.4 modem signals and general-purpose i/o each channel of the CD1865 has four pins that can be used either as modem-control or general- purpose input/output pins. the modem signal names assigned to these four pins have been chosen to provide an easy reference for systems designers. in fact, they are all simply general purpose inputs and outputs (if automatic out-of-band flow control is not used) that can be individually controlled by the modem signal value register(s). since they are general purpose, system designers may choose to connect the pins in any way that suits the application. txfloff txflon meaning 1 1 illegal 1 0 transmitter is flow-controlled off 0 1 transmitter on, no data sent yet 00 transmitter on, CD1865 has sent data, or implied xon has occurred. this is also the ? normal ? state of these bits when flow control is not being used
intelligent eight-channel communications controller ? CD1865 datasheet 79 however, when the system software design chooses to make use of the automatic out-of-band flow control with the pins, then the signal naming convention no longer holds true in some cases, depending on whether the device is used as dce or dte. in this case, it is best to think of the pins in terms of their actual uses within the CD1865 and connect them accordingly, without regard to their names. the rts* and cts* pins are associated with the transmitter and the dtr* and dsr* pins are associated with the receiver. the table below shows intel ? s recommended signal hook-up if automatic, out-of-band flow control is required. for example, if the CD1865 is designed to be a dce and automatic out-of-band flow control is required, the pin labeled dtr should be connected to remote cts input. if the CD1865 is to be used as the dte side, then the CD1865 cts output would be connected to the remote cts input. note that if automatic out-of-band flow control is implemented, the activity of dtr and dsr pins do not implement the function assigned to those signal names by the signalling conventions of the ccitt and other standards organization. these names would only apply to these pins if they are under program control and not under automatic CD1865 control. in fact, the ? dtr ? function, as defined, enables the modem to go on- and off-line, depending on the state of the pin. if automatic control is used, then dtr would go inactive when the receive fifo reached the programmed threshold thus causing the modem to drop the connection (carrier) to the remote, which would not be the correct function. refer to section 7.3 for details on operation of modem pins in flow-control applications. modem pins are implemented as i/o ports accessible by either the CD1865 processor or the host. the modem pins are not connected directly to the transmit or receive hardware. when a user programs out-of-band modem functions to be active, the CD1865 processor reads from and writes to these pins. specifically, when rts* and cts* are being used for transmit flow control, the CD1865 processor asserts rts* and senses cts*, as required. likewise, when configured to do so, the receive fifo negates dtr* when full. the host should not be allowed to re-assert it inadvertently. the host is not ? locked out ? of accessing these bits; care should be taken so that these bits are not written to, causing the system to malfunction. the user has direct control over the rts* and dtr* outputs and can sense the state of cts*, cd*, and dsr* inputs through the modem signal value register (msvr). since the host is accessing these pins directly, there is no delay in the host's ability to detect a level change. dtr* and cd* depend on the state of the dtrsel input. dce dte CD1865 pins out-of-band flow control cts dtr signal remote to transmit rts not implemented in this direction rts rts request remote permission to transmit cts cts enable transmitter modem control pins function rts* request to send (general-purpose output) cts* clear to send (general-purpose input) dtr* data terminal ready (carrier detect/general- purpose input/output) dsr* data set ready (general-purpose input) cd* carrier detect (general-purpose input)
CD1865 ? intelligent eight-channel communications controller 80 datasheet when the CD1865 is programmed to detect level changes and generate service requests when level changes occur, it does so in firmware by reading the pins and comparing to a previously stored value. this function is performed in the main timing loop of the firmware; the maximum time required to detect a level change under worst-case conditions is approximately 2 ms. when the CD1865 is performing this function, the modem pins are periodically sampled rather than continuously monitored; as such they have very little sensitivity to noise, which is desirable in data communication applications. however, in extremely noisy applications, re-read a modem line which has caused a modem signal change service request to verify that it has indeed changed and is not merely malfunctioning. this eliminates even the slight possibility of a noise pulse causing erratic operation. when the CD1865 is monitoring modem pins to control transmit or receive functions, it does not rely on the previously stored value, but checks the pins at the appropriate time. thus, there is very little delay in this response. for example, before deciding to transmit another character, it examines the cts* pin at that time. (the CD1865 makes this decision when moving characters from the fifo to the holding register, not from the holding register to the shift register.) refer to section 7.3 on page 72 for flow-control details. note that the logical sense of the modem bits is inverted; for example, writing a ? 1 ? to the msvr causes the output pin to go to nominal zero volts. likewise, a low-voltage input is sensed as a ? 1 ? . 7.4.1 generating service requests with modem pins the CD1865 can generate service requests when any one of the input pins changes state. either or both edges may be detected by setting bits in the two modem change option registers (mcor1 and mcor2). for each pin, the user can individually enable on-to-off or off-to-on transition detection of the inputs. when the CD1865 detects such a transition, it sets the corresponding bit in the modem change register. if the corresponding bit in the channel ? s set, the CD1865 asserts its * output. the user must clear the modem change register during the service request service routine before writing to the . the CD1865 performs this task by reading the modem input signals and comparing the current value with the value read in the last pass through the outer scanning loop. because this is the lowest-priority event in the CD1865 scanning loop, changes may not be detected unless they are several hundred microseconds long. modem input pins can be used for purposes such as detecting the closing of a switch. however, the relatively slow speed of response should be taken into account when using modem input pins for this purpose. the CD1865 does not latch the modem input signals. 7.4.2 using modem pins as general-purpose i/o since the modem pins can be directly accessed by the host, they can be used as general-purpose i/o pins if they are not needed for flow control or modem interfacing. simply read from and write to them as any i/o port. 7.5 testing the CD1865 ? loopback tests the CD1865 performs a basic internal self-test whenever it is reset. this test provides a reasonable degree of confidence that the CD1865 is functioning satisfactorily. there are two additional tests that can be performed by the user to further ensure complete functionality. these two test modes
intelligent eight-channel communications controller ? CD1865 datasheet 81 are local and remote loopback. used together with diagnostic firmware in the host system, the loopback modes provide very thorough test coverage of all CD1865 functional blocks: the CD1865 processor, rom, ram, bus interface, transmitters/receivers, and random logic. local loopback mode local loopback mode is a ? silent ? loopback, for example, data being sent by the transmitter is internally connected to the receiver without reaching the external txd pin. generally, this is advantageous because it allows diagnostic software to operate without causing unwanted effects on any remote device that may be connected to the serial line. during local loopback, the txd pin is in the ? mark ? (a logic ? 1 ? ) state. if non-silent loopback is also needed, it can be easily implemented externally with an and gate or a jumper plug on the serial connector. local loopback mode is invoked by setting the llm bit in the channel option register 2 (cor2) and then issuing a channel command to tell the CD1865 that cor2 has changed. when in this mode, the channels txd output is internally looped back to the channel ? s rxd input. however, all other channel parameters including modem pins continue to work independently and normally. receive special character recognition, overflow handling, and other options may be tested by using the local loopback mode and transmitting the appropriate character sequences. as shown in figure 27 on page 82 , the loopback connection is directly from the txd signal to the rxd signal, for example, all transmit and receive logic is tested except the actual i/o buffers. remote loopback mode remote loopback mode is provided to support testing of devices connected to the serial lines. remote loopback is invoked by setting the rlm bit in the channel option register 2 (cor2). when in this mode, the CD1865 echoes the received data to the transmitter for transmission back to the sender. the received data is not passed on to the host. when in remote loopback mode, the transmitter continues to run as defined by its own baud rate registers, not the values being used by the receiver. the CD1865 receives a complete character, strips off start, stop, and parity bits, and then re-transmits it with parity, length, and stop bit output options as defined in cor1. thus, it is possible to change baud rate. however, this can result in receiver overflow. in general, when programming for remote loopback operation, the transmit bit rate should be as fast or slightly faster than the expected receive rate to avoid possible overrun and loss of data. the number of stop bits should be set to a one, rather than one-and-a-half or two, if the application permits it. this ensures that the effective transmit rate is faster than the receive rate. as shown in figure 27 , remote loopback is done at the character level and not the bit level. the receive and transmit fifos are not used in remote loopback. characters are transferred directly from the receive holding register to the transmit holding register. for a diagnostic mode that tests the fifos, other logic is needed to be implemented by programming the host system to transfer received characters from the receive fifo to the transmit fifo. this permits full testing of fifo thresholds, service request logic, special character operation, and so on.
CD1865 ? intelligent eight-channel communications controller 82 datasheet figure 27. local and remote loopback logic transmit shift register transmit holding register receive holding register receive shift register receive fifo transmit fifo local loopback switch remote loopback switch
intelligent eight-channel communications controller ? CD1865 datasheet 83 8.0 programming 8.1 types of registers the CD1865 contains three types of registers: global registers ? registers not specific to a particular channel indexed indirect registers ? special registers that are mapped to unique functions channel registers ? registers specific to each channel global registers global registers contain information common to all channels. they are used primarily for passing vectors and setting-up service request handling. indexed indirect registers indexed indirect registers are special registers that either point to the fifos or signal the end-of- service request processing. the indexed indirect registers are used primarily to transfer data to and from the serial channel fifos. such transfers can be done only during a service request. when service requests are being serviced by the host, a context-switching technique is used by the CD1865 that reduces the number of cycles needed by the host to transfer data to and from the CD1865. the CD1865 makes available to the host all the registers pertaining to the channel requesting service by mapping them through to the indexed indirect register addresses. this removes the burden, of keeping different addresses according to which channel is being accessed, from the host. fifo information is channeled through either the receive data register, the receive character status register, or the transmit data register of the indexed indirect register set. use of the indexed indirect registers is valid only during appropriate service requests; the transmit data register can be accessed during transmit service requests, but not during receive or modem service requests. the channel access register ? s (car) content is left unchanged from the value last set by the user, but it is not used in a service request context. the car should not be modified during a service request. during a service request, only access the channel that has caused the service request to be issued (as defined by the global interrupting channel register). channel registers channel registers are used to store parameters specific to each channel, such as bit rates, special character processing, and modem options. when not actively involved in a service request, each channel can be accessed at any time, independently of the other channels. channel registers can be accessed by first writing the number of the channel to be accessed into the channel access register. the channel number in the car is used by the CD1865 as part of the channel register address. individual CD1865 registers are addressed by a seven-bit address contained in address bus bits a6-a0. address bit a6 set to a ? 1 ? selects the global registers, and when set to a ? 0 ? selects the channel registers. when the CD1865 is not in a service request context, the active channel is defined in the car. the contents of the car then become part of the address field (along with a0 ? a5) needed to access the channel register file.
CD1865 ? intelligent eight-channel communications controller 84 datasheet off-limit registers the CD1865 communicates to the host by shared access to its on-device ram. of the 128-byte locations in the CD1865 address range, only 41 locations are defined as registers available to the host. the rest are used by the CD1865 for internal variable storage. users should not access these registers since it can cause the CD1865 to malfunction. 8.2 access duty cycle the host access to the CD1865 appears to be a simple static read or write cycle, but the actual access occurs by arbitrating for the local (on-device) bus and ? stealing ? one-bus cycle. this is completely hidden from the user in normal circumstances, and successive accesses to the CD1865 may be done ? back-to-back ? with no delay. however, if the host were to repetitively read from (or write to) the CD1865 as fast as possible over many cycles, enough CD1865 internal bus cycles would be ? stolen ? that the CD1865 processor might not be able to keep pace with its processing. this situation could only occur if the host was continuously testing a bit while waiting for it to change state. if there is a requirement to do something similar, insert a delay in the host code so that the net-duty cycle of accesses is less than ten percent. this limitation applies only when the CD1865 is sending and receiving data on one or more channels. when initializing or re- configuring a channel, these registers can be written to at a fast pace. 8.3 accessing fifos versus other registers the fifo storage array is under the control of the CD1865 at all times. this is necessary to ensure that the fifo is available for the CD1865 processor to access whenever needed. during normal operation, the CD1865 processor sets the fifo pointers to the value required to transfer data, regardless of the value placed in the channel access register (car) by the user. therefore, the user cannot access the fifos in this manner. fifos can only be accessed in the context of an active service request. at this time only the CD1865 processor causes the fifo pointers to be set to the appropriate value for the channel being serviced. fifos are then accessed by the indirect indexed registers. 8.4 initialization the CD1865 initialization begins with a mandatory hardware reset applied through the active-low reset* input. the system clock (clk) input must be active during the hardware reset, and the reset duration must be at least five clock periods. it is not necessary to synchronize reset* input with clk. refer to figure 28 . immediately following the hardware reset, the CD1865 goes through a firmware initialization, reaching an idle mode within 500 s. this can be verified by the host by reading the global service vector register and finding its contents to be ff hex. upon internal reset completion, the user can then configure the CD1865 for the required channel functions. a software reset can be performed by setting certain bits in the channel command register (ccr). setting bits 7 and 0 to a ? 1 ? resets all channels. this is done by forcing the CD1865 processor to jump to the same power-up sequence that it uses upon hardware reset. whether the reset is caused
intelligent eight-channel communications controller ? CD1865 datasheet 85 by hardware or software, the CD1865 does not initialize every register and ram location to a defined value. the only sure state is that all channels are inactive, no service requests are pending, and the global interrupt vector register is ff hex. figure 28. initialization initialization n y master chip reset global initialization channel initialization y load schr1-3, msvr, mcor1-2, transmit/receive load gsvr with chip id, pilrs with vectors, and prescale registers load cor1-3 with character settings issue cor change command in ccr load car with a ? 0 ? n y done gsvr = ff ? ccr = 0 ? last channel (car=8) ? increment car n and operation modes after either a hardware reset by the reset pin or a software reset by a ccr command, wait until the gsvr= xff before proceeding with chip initialization. when the CD1865 is ready, begin by loading the gsvr with the the service match registers with the vectors that will be used during service acknowledge cycles. load the prescale registers with the value chosen for the basic time count for timer operations. in preparation for channel initialization, load the car with a ? 0 ? to access channel zero registers. for the ccr to contain a value of zero to ensure that the CD1865 is not processing a previous change command for that channel. load the channel option registers with the values to enable the desired modes of operation and character parameters such as parity, stop bits, and so on. inform the CD1865 that one or more channel option registers have changed via the cor change command. option registers for modem interrupt conditions; the msvr with the bits in the srer register for the interrupt conditions desired. if more channels, go back to the top of the loop. chip id if there are more than one CD1865 in the system. load states of dtr/rts as necessary and the baud rate constants for transmit and receive baud rate generators. set the appropriate
CD1865 ? intelligent eight-channel communications controller 86 datasheet 8.5 global register initialization the user must initialize the CD1865 by programming the following global registers before starting normal operations on the ports ? prescaler period registers, the global interrupt vector register, and the three service match registers (). 8.6 service request initialization to prepare the CD1865 for service requests the following registers must be initialized: global register (gvr) three service match registers () global channel registers (gcr) the global vector register consists of five bits of user-supplied information, and three bits of CD1865 ? supplied service request group information. this concatenated vector supplied by the CD1865 during a service-request-acknowledgment cycle directs the host to the proper service request subroutine. the host writes the five msbs into the gvr during initialization. these five bits can be either a device id number or an appropriate code for handling service request. in multiple-cascaded CD1865 applications, these five bits must have a unique value for each CD1865 to identify which CD1865 is responding to a service request cycle. three registers in the global register set ? modem service match register (), transmit service match register (), and receive service match register () store the service request values for the three types of service requests. these levels are used to match with the value that appears on the address bus during a service-request-acknowledgment cycle. since these levels are system dependent, the user must initialize these registers with the proper values. the following three registers provide the channel number of the channel requesting service ? gcr1, gcr2, and gcr3. reading any of these registers causes the CD1865 to ? mask-in ? three bits specifying the channel number of the currently active channel. normally these registers are read by the host when it is handling a service request. in this case, the three bits are the number of the channel requesting service. if any of the three gcr registers are read when the CD1865 is not in a service request context, the three bits are the current value in the car. bits 4:2 are masked into the contents of these registers by the CD1865 when it is read by the host. the actual contents of the register are not modified. these three registers are provided as a convenience to the user. in most applications the user only uses one of these locations and sets the register to an arbitrary value. however, in some cases it may be useful to be able to record information about the state of the CD1865 (or the software driving it) that is associated with each of the three service request types. in this case, the user may store required information in the unused bits. when entering a service routine, the software can check these bits (a ? sub-vector ? ) to read recorded states. 8.7 prescaler the prescaler period register (ppr) determines the fundamental ? tick ? rate for all CD1865 on- device timers, the receiver data time-out and transmitter real-time delay timers. the ppr counts clock (clk) periods, and the minimum ppr value used must guarantee a ? tick ? length of
intelligent eight-channel communications controller ? CD1865 datasheet 87 not less than 1.0 milliseconds. as shown in the internal operation flow chart, figure 4 on page 25 , processing timer events is in the outer (lowest priority) loop of the CD1865 firmware. a timer tick that is too short may result in two ticks occurring within one pass through the outer loop; this would result in missing one tick. this is not fatal, but it would result in inaccurate timings. 8.8 channel initialization and changes prior to enabling the individual channels, program the channel registers with required channel options and parameters such as character lengths, parity type, receive fifo thresholds, modem signal detection levels, bit rates, and so on. when ready to begin, enable service requests. channel initialization is accomplished by first writing to the car register with the number of the channel to be programmed. this channel number automatically becomes part of the address for subsequent channel register programming. the host can use the same set of register addresses for all channels, thus eliminating the need to calculate addresses. certain channel options are controlled by the three channel option registers. all changes to the channel option registers must be accompanied by setting the appropriate channel option register ? changed ? bits in the channel command register (ccr). the CD1865 processor regularly samples the ccr for any value that is not a ? 0 ? . if the ccr is not a ? 0 ? , the CD1865 decodes the command or commands, acts on them, and clears the ccr to signify completion of the commands. new commands must not be issued until any existing commands have been completed. 8.9 transmitting data when transmitting data, a service request is received when the transmit fifo is empty. the number of the channel requesting service (for example, the one with the empty fifo) is available from the gcr. if there is more data to be sent, transfer up to 8 bytes to the fifo. if no data is available, disable the channel. the easiest way to accomplish this is by clearing the appropriate bit in the enable register (). when new data is available, re-enable the channel by the , and a new service request for transmit data is received. at that time, transfer the data to the fifo. channels can be enabled or disabled by giving enable and disable commands by the channel command register (ccr), but it is a slower process. in some cases, it is necessary to know when a channel has sent the last bit of the last character rather than an empty fifo. one example would be when changing bit rates. two bits in the enable register (), txmpty and txrdy, control the exact conditions for generating a service request. txrdy indicates when the fifo is empty, and txmpty indicates when the last bit has been sent. it is acceptable to have both bits set but proper operation is achieved by switching from the fifo empty status to the transmitter empty status when it is necessary to know that all data has been completely sent. if they are set, the fifo empty service request always occurs first. if there is no more data to be sent, the transmitter empty service request is received later, but in the mean time, fifo empty requests may also be received. once the last bit of the last character has been sent, a channel can be reconfigured.
CD1865 ? intelligent eight-channel communications controller 88 datasheet 8.10 receiving data when receiving data, a service request is sent (for good data) when either the number of received bytes meets the threshold level, the receive time-out expires, or there is good data followed by a receive exception condition (the CD1865 must transfer all the good data before giving the exception). in all cases, the service-request routine reads the channel number requesting service (from gcr) and the number of bytes available (which can be more, the same, or less than the number set as the threshold) from the receive data count register (rdcr), and proceeds to transfer that many bytes, if possible. it is not necessary to transfer as many bytes as are available or any bytes at all. if the host ? s buffer is nearly or completely full, the host can accept only those bytes it has room for, disable receive service requests, exit the service request routine, process the buffer, enable receive service requests, and wait for the next service request. if no bytes are transferred during a receive service request, and receive service requests are still enabled, the CD1865 immediately re-requests service because the internal conditions that caused the request to be issued are still true. the host may either disable service requests or suspend host service request processing; however, both of these options should be implemented carefully as suspending service requests may result in an overflow condition if the suspension lasts too long. 8.11 programming examples when writing programs for the CD1865 evaluation board, a few guidelines should be followed to keep the programs from getting lost or error conditions to be encountered. this section discusses some programming errors and ways to avoid them. 8.11.1 programming the service match registers one common programming error is made when using the CD1865 in the area of service match registers (smr). the value placed in these three registers during chip initialization must exactly match the value that is present on the address inputs a0 ? a6 during the service acknowledge cycle. (when the ackin* control signal is activated.) if this condition is not met, the CD1865 does not respond with a dtack* to terminate the bus cycle. this causes the system to hang. 8.11.2 CD1865 initialization initializing the CD1865 is simple and quite straight forward. this section presents some guidelines for the sequence to write to the various registers to correctly complete the initialization process. refer to section 8.4 on page 84 for a flow-chart style description of the process. the first step in the initialization process is to issue a master reset command to the CD1865 internal logic. this can be done in one of the two ways: throughout the use of the reset* control signal at the hardware level, or via the chip reset command at the software level. the software reset command is issued by placing a value of x ? 81 in the ccr register. internally the chip reset command does the same thing as activating the reset* control input. the internal micro-code enters the exact same routines to setup the chip for operation. when the reset command has been issued, the program must wait until the gsvr has a value of x ? ff. until this value is placed in the gsvr by the micro-code, the CD1865 initialization procedures are not complete.
intelligent eight-channel communications controller ? CD1865 datasheet 89 the next function to be performed is global initialization. these steps set up the chip id for the CD1865, the service match registers (smr) for the three service request levels and the prescaler period register. the smr should be programmed as discussed previously ( section 8.1 ). the prescaler period register value (high and low) sets the basic time scale for internal timer operation, such as the receiver time-out period. a value must be chosen that yields a timer period of no less than 0.1 ms. following global initialization, each channel must be programmed for the desired mode of operation, including the transmit and receive baud rate divider constants, the individual character settings such as parity, bits per character, and number of stop bits. receive fifo threshold levels, special character values, modem output signal levels and interrupt conditions. before beginning the process of channel initialization, the car register must be loaded with the number of the register to be worked on. one important point to remember is that before placing a new value in any of the cor registers or issuing the cor change command, the ccr must be checked to be sure that it has a value of zero. if it is not zero, then the CD1865 may be processing a previous ccr command and the ccr and the cors must be changed. if the program is ready at this point to respond to interrupts then the appropriate interrupt condition bits for transmit and receive can be set in the srer, and the transmitter and receiver can be enabled by command to the ccr. the following sections explain the initialization sequence. global initialization use set_byte to write to the register, and read_byte to read the register content. for details on the two functions, refer to the following basic i/o operations. set_byte(gsvr, 0x00); // clear gsvr for chip reset wait_ccr(); // confirm ccr is clear set_byte(ccr, 0x81); // reset all command wait_gsvr(); // wait to be ff set_byte(pprh, 0x80 ); // set up timer prescaler (high) set_byte(pprl, 0xe8 ); // set up timer prescaler (low) /*------------------------------------------------------------------------- /* set up the service match register according to the decoding ackin value /* in this case, we decoded to be 0x8x. /*-------------------------------------------------------------------------*/ set_byte(rx_smr, 0x8a ); // set service match reg. set_byte(tx_smr, 0x85); set_byte(mdm_smr, 0x81); // comment out the following line if is using the hardware acknowlegement. //set_byte(srcr, 0x40); // set up the software interrupt acknowledge channel initialization set_byte(car, chan); // setup channel access register to be the // specified channel number. set_byte(cor1, 0x03); // no parity, 8-bit char, 1-stop bit set_byte(cor2, 0x00); // disable all cor2 functions set_byte(cor3,0x35); // special char detection, fct wait_ccr(); set_byte(ccr, 0x4e); set_byte(schr1, 0x11); // xon defined (cntl-q 0x11) set_byte(schr2, 0x13); // xoff defined (cntl-s 0x13) set_byte(schr3, 0x11);
CD1865 ? intelligent eight-channel communications controller 90 datasheet set_byte(schr4, 0x13); set_byte(rtpr, 0x05); // set timeout value set_byte(tbprh,0x00); // set tx baud rate 115200 (devisor 0x12) at 33 mhz set_byte(tbprl,0x12); set_byte(rbprh,0x00); // set rx baud rate 115200 (devisor 0x12) at 33 mhz set_byte(rbprl,0x12); 8.11.3 basic i/o operations all the example routines for accessing and programming the board resources are written in borland ? c++, but can be easily ported to other languages. specific device programming is not included in this document; refer to the device data book for general programming information. read_byte routine is used to read a register within the CD1865. the sequence is shown below: // read the content of assigned register unsigned char read_byte( unsigned char addr ) { return ( inportb( base_addr+addr ) ); } set_byte routine is used to write to the register and is a similar operation as the read_byte. // set the content of assigned register void set_byte( unsigned char addr, unsigned char data) { outportb(base_addr+addr, data); } 8.11.4 interrupt response operations the CD1865 evaluation board generates a single interrupt to the isa bus in response to an interrupt from any of the three possible sources within the CD1865 device. the interrupt sources are from the receive system, the transmit system, or the modem functions from any of the available channels. this single interrupt can be user selected to any of the three isa -bus interrupt sources as described in the configuration section. note that due to all the interrupt signals being or ? ed together, the pc motherboard 8259a pic must be programmed in level sensitive rather than edge- sensitive mode. determining the interrupt source the host ? s response to an interrupt from the board is to call an interrupt service routine that determines the type of interrupt pending and services the request. the example below shows one way to perform the interrupt determination using the interrupt status register. while ( (int_status = read_byte( srsr )) & 0x15 ){ // case of receiving interrupt if ( int_status & 0x10 ) service_rx(chan); // case of transmitting interrupt if ( int_status & 0x04 ) service_tx(chan);
intelligent eight-channel communications controller ? CD1865 datasheet 91 if (int_status & 0x02) service_mdm(); } //while outportb(s8259, eoi); /* end of interrupt */ outportb(s8259, rdistat); /* next access read the is reg. */ if ( !inportb(s8259) ) /* while the slave is not serving any int. */ outportb(m8259, eoi); /* issue end of int. (eoi) to master */ once the interrupt source has been determined, the request must be serviced by issuing an iackin signal to the device with the preprogrammed pilr match value supplied as the address. a receive interrupt acknowledge cycle might be written as shown. immediately following the write to the eoir register to terminate the current interrupt context, the 8259a must be informed that the service is over. this is done by the simple procedure shown at the end of the interrupt source determination routine above. receive interrupt service service_rx(unsigned char chan) { unsigned charchannel, vector, rxcount; int i; vector= read_byte(0x8a); // perform hardware acknowledge channel = read_byte(gscr1) >> 2; rxcount=read_byte(rdcr); // rdcr contains the number of byte to be transfered. if ((rxcount>0)&&(rxcount<=8)) { if ((exception_data = read_byte(rcsr)) != 0) // receive exception: in this // example, we disable receive // operation if detected a receive // exception. { set_byte(car, chan); set_byte(srer, 0x00); // disable receive } else // normal receive operation: no // receive exception. { if (channel==chan){ // correct receiving channel for (i=rxcount; i>0; i--){ rx_str[rx_ptr]=read_byte(rdr); rx_ptr++; }//for }//if else // incorrect receiving channel rx_chan_err = 1; } // else } //if set_byte(eosrr, 0x00); // set transmit end of int reg. the transmit end of // interrupt register must be written to by the // corresponding host interrupt service routine to
CD1865 ? intelligent eight-channel communications controller 92 datasheet // signal to the CD1865 that the current interrupt // service is concluded. return; } transmit interrupt service service_tx(unsigned char chan) { unsigned char channel, vector,c; int i; vector= read_byte(0x85); // perform hardware acknowledge channel = read_byte(gscr1) >> 2; if (channel==chan){ // make sure correct channel for (i=1; i<= 8 && !quit_tx ; i++){ set_byte(tdr, txm_str[tx_ptr[chan]++] ); if (tx_ptr[chan] >= strlen(txm_str) ){ tx_ptr[chan] = 0; // reset the pointer back to the quit_tx = 1; } }//for }//if else tx_chan_err = 1; // wrong transmitting channel. set_byte(eosrr, 0x00); // set transmit end of int reg. // the transmit end of interrupt register must // be written to by the corresponding host // interrupt service routine to signal to the // CD1865 that the current interrupt service // is concluded. return; } modem interrupt service service_mdm() { unsigned char channel, vector; vector = read_byte(mrar); // software acknowledge using mrar //vector = read_byte(0x81); // comment out the previous line, if using // hardware acknowledge. channel = read_byte(gscr1) >> 2; switch(read_byte(mcr)&0xe0) { case 32: // case of cts change interrupt { printf(" ctr has a changed state. \n"); break; } case 64: // case of cd change interrupt { printf(" cd has a changed state.\n"); break;
intelligent eight-channel communications controller ? CD1865 datasheet 93 } case 128: // case of dsr change interrupt { printf(" dsr has a changed state.\n"); break; } default: { printf(" invalid modem interrupt detected.......\n"); break; } } set_byte(mcr, 0x00); // clear the modem change register after // service the modem request. set_byte(eosrr, 0x00); // clear the eosrr register at the end // modem service routine. return; } 8.11.5 polled mode operation the polled-mode operation can be used with any type of host cpu, or it can be used in combination with interrupts to provide a mixed-mode system optimized for a particular operation. for details refer to section 5.5 on page 35 . in the polled-mode operation, the service match registers need to be setup first (tsmr, rsmr, msmr) in the channel initialization routine. once an interrupt is detected, it is acknowledged by reading the corresponding register depending on the type of interrupt. while ( !((int_status = read_byte( srsr )) & 0x15 ) ) { // waiting for interrupt. break; } // case of receiving interrupt if ( int_status & 0x10 ) { read_byte(rsmr) service_rx(); } // case of transmitting interrupt if ( int_status & 0x04 ) { read_byte(tsmr) service_tx(); } // case of modem interrupt if (int_status & 0x02) { read_byte(msmr) service_mdm(); }
CD1865 ? intelligent eight-channel communications controller 94 datasheet 9.0 detailed register descriptions 9.1 register map quick reference name description access binary address default value hex address (8 bit) 1 hex address (intel ? ) 2 hex address (motorola ? ) 3 page global registers gfrcr global firmware revision code register r/w 110 1011 84 $6b 4 $d6 $d7 98 srcr service request configuration register r/w 110 0110 0 $66 $cc $cd 98 pprh prescaler period register high r/w 111 0000 ff $70 $e0 $e1 100 pprl prescaler period register low r/w 111 000 ff $71 $e2 $e3 100 msmr modem service match register r/w 110 0001 0 $61 $c2 $c3 100 tsmr transmit service match register r/w 110 0010 0 $62 $c4 $c5 101 ssvr receive service match register r/w 110 0011 0 $63 $c6 $c7 101 global vector register r/w 100 0000 ff $40 $80 $81 102 srsr service request status register r 110 0101 0 $65 $ca $cb 103 mrar modem request acknowledge register r 111 0101 80 $75 $ea $eb 105 trar transmit request acknowledge register r 111 0110 80 $76 $ec $ed 105 rrar receive request acknowledge register r 111 0111 80 $77 $ee $ef 105 gscr1 global channel register 1 r/w 100 0001 0 $41 $82 $83 106 gscr2 global channel register 2 r/w 100 0010 0 $42 $84 $85 106 gscr3 global channel register 3 r/w 100 0011 0 $43 $86 $87 106 car channel access register r/w 110 0100 0 $64 $c8 $c9 107 indexed indirect registers rdcr receive data count register r 000 0111 0 $07 $0e $0f 108 rdr receiver data register r 111 1000 0 $78 $f0 $f1 109 rcsr receiver character status register r 111 1010 0 $7a $f4 $f5 110 tdr transmit data register w 111 1011 0 $7b $f6 $f7 111 eossr end of register w 111 1111 0 $7f $fe $ff 111 notes: 1. hex address for 8-bit processor. 2. address for intel-style processor, see the following description. 3. address for motorola-style processor, see the following description. 4. $ denotes address value.
intelligent eight-channel communications controller ? CD1865 datasheet 95 channel registers srer enable register r/w 000 0010 0 $02 $04 $05 112 ccr channel command register r/w 000 0001 0 $01 $02 $03 112 cor1 channel option register 1 r/w 000 0011 0 $03 $06 $07 116 cor2 channel option register 2 r/w 000 0100 0 $04 $08 $09 116 cor3 channel option register 3 r/w 000 0101 0 $05 $0a $0b 117 ccsr channel control status register r 000 0110 0 $06 $0c $0d 118 rbr receiver bit register r 011 0011 21 $33 $66 $67 119 rtpr receive time-out period register r/w 001 1000 5 $18 $30 $31 120 rbprh receive bit rate period register high r/w 011 0001 0 $31 $62 $63 120 rbprl receive bit rate period register low r/w 011 0010 0 $32 $64 $65 120 tbprh transmit bit rate period register high r/w 011 1001 0 $39 $72 $73 121 tbprl transmit bit rate period register low r/w 011 1010 0 $3a $74 $75 121 schr1 special character register 1 r/w 000 1001 0 $09 $12 $13 121 schr2 special character register 2 r/w 000 1010 0 $0a $14 $15 122 schr3 special character register 3 r/w 000 1011 0 $0b $16 $17 122 schr4 special character register 4 r/w 000 1100 0 $0c $18 $19 123 mcr modem change register r/w 001 0010 0 $12 $24 $25 123 mcor1 modem change option register 1 r/w 001 0000 0 $10 $20 $21 124 mcor2 modem change option register 2 r/w 001 0001 0 $11 $22 $23 125 msvr modem signal value register r/w 010 1000 0 $28 $50 $51 125 msvrs modem signal value request to send w 010 1000 0 $29 $52 $53 126 msvdr modem signal value data terminal ready w 010 1010 0 $2a $54 $55 126 name description access binary address default value hex address (8 bit) 1 hex address (intel ? ) 2 hex address (motorola ? ) 3 page notes: 1. hex address for 8-bit processor. 2. address for intel-style processor, see the following description. 3. address for motorola-style processor, see the following description. 4. $ denotes address value.
CD1865 ? intelligent eight-channel communications controller 96 datasheet even though not all of the CD1865 registers are intended to be read/write, there is no hardware mechanism to prevent the user from writing to them. the registers should, in some cases, not be written to by the host. see the individual register descriptions for details. in the register map, the binary addresses are shown relative to the CD1865 address lines. in 16- and 32-bit systems, it is a common practice to connect 8-bit peripherals to only 1-byte lane. in 16-bit systems, the CD1865 appears at every other address, that is, a0 in the CD1865 is connected to a1 in the host. in 32-bit systems, the CD1865 appears at every fourth address, that is, a0 in the CD1865 is connected to a2 in the host. in both of these cases, the addresses used by a programmer are different than what is shown. for instance, in a 16-bit motorola 68000-based system (or other ? big-endian ? processors), the CD1865 is placed on data lines d0 ? d7 that are at odd addresses in the motorola manner of addressing. the a0 in the CD1865 is connected to a1 of the 68000. thus, the CD1865 address $40 becomes $81 to a programmer. it is ? left-shifted ? one bit, and a0 must be ? 1 ? for low-byte (d0 ? d7) accesses. in a 16-bit intel system (or other ? little-endian ? processors), the CD1865 is again placed on data lines d0 ? d7, but these are at even addresses. the a0 in the CD1865 is connected to the a1 in the host, but the host ? s a0 must be a ? 0 ? to access data lines d0 ? d7. many 32-bit processors have internal logic to ? steer ? the data to the correct pins regardless of address value. however, if the processor employed does not, a scheme similar to the one described for 16-bit machines can be used, except that the CD1865 addresses are shifted 2 bits instead of one. table 9. register summary (sheet 1 of 2) namebit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 global registers gfrcr firmware revision code srcr pkgtyp regacken daisyen globpri unfair reserved autopri prisel pprh binary value pprl binary value msmr binary value tsmr binary value rsmr binary value gsvr user defined user defined user defined user defined user defined it2 it1 it0 srsr ilv[1] ilv[0] rreqext rreqint treqext treqint mreqext mreqint mrar modified interrupt vector provided on read trar modified interrupt vector provided on read rrar modified interrupt vector provided on read gscr1 user defined user defined user defined c2 c1 c0 user defined user defined gscr2 user defined user defined user defined c2 c1 c0 user defined user defined gscr3 user defined user defined user defined c2 c1 c0 user defined user defined car reserved reserved reserved reserved a7(0) c2 c1 c0
intelligent eight-channel communications controller ? CD1865 datasheet 97 9.2 global registers global registers provide a function common to all channels. there are two groups of global registers: those that control the configuration of the CD1865 and those that control service requests/interrupts. indexed indirect registers rdcr 0 0 0 0 ct3 ct2 ct1 ct0 rdr d7 d6 d5 d4 d3 d2 d1 d0 rcsr time-out sc det2 sc det1 sc det0 break pe fe oe tdrd7d6d5d4d3d2d1d0 eosrr irrelevant value channel registers srer dsr cd cts rxd rxsc txrdy txmpty nndt ccr reset chan cor chng send sp ch chan ctl d3 d2 d1 d0 cor1 parity parm1 parm0 ignore stop 1 stop 0 chl 1 chl 0 cor2 ixm txibe etc llm rlm rtsao ctsae dsrae cor3 xon ch xoff ch fct scde rxth3 rxth2 rxth1 rxth0 ccsr rxen rxfloff rxflon not used txen txfloff txflon not used rbr reserved rxd start hunt reserved reserved reserved reserved reserved rtpr receiver data time out period rbprh receive bit rate divisor byte high rbprl receive bit rate divisor byte low tbprh transmit bit rate divisor byte high tbprl transmit bit rate divisor byte low schr1 special character 1 schr2 special character 2 schr3 special character 3 schr4 special character 4 mcr dsrchg cdchg ctschg 0 0 0 0 0 mcor1 dsrzd cdzd ctszd 0 dtrth3 dtrth2 dtrth1 dtrth0 mcor2 dsrod cdod ctsod 0 0 0 0 0 msvr dsr cd cts not used not used not used dtr rts msvrts0000000rts msvdtr000000dtr0 table 9. register summary (sheet 2 of 2) namebit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0
CD1865 ? intelligent eight-channel communications controller 98 datasheet 9.2.1 miscellaneous registers 9.2.1.1 global firmware revision code register this register is initialized by the firmware during the power-on reset initialization routine to contain the current firmware version code of the CD1865. this register is a ram location and may be modified by the user. the CD1865 sets it to the defined value only when a hardware or software reset is performed, and its contents are otherwise ignored. this value can be modified to indicate the configuration status of the CD1865, or to indicate any other requirement. 9.2.2 configuration registers 9.2.2.1 service request configuration register this register configures the CD1865 depending on the method chosen for handling service requests. in addition to the ? traditional ? interrupt-based host interface, writing the appropriate bits in this register provides for software- rather than hardware-based service request acknowledgments, fixes service request priorities in either of two ways, and controls fair share interrupt operation. this register preserves compatibility with existing CD1865 software. for this reason, this register defaults to all zeroes and must be enabled for each new feature as required. regacken and daisyen bits are related to each other, and perform service-request acknowledgments by accessing registers within the CD1865 instead of asserting hardware signals. service requests are prioritized by four other bits. autopri enables the priority scheme; prisel, globpri, and unfair determine the specific priority to be used. register name: gfrcr register description: global firmware revision code register default value: 84 access: read/write 8-bit hex address: $6b intel hex address: $d6 motorola hex address: $d7 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 firmware revision code register name: srcr register description: service request configuration register default value: 0 access: read/write 8-bit hex address: $66 intel hex address: $cc motorola hex address: $cd bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 pkgtyp regacken daisyen globpri unfair reserved autopri prisel
intelligent eight-channel communications controller ? CD1865 datasheet 99 bit description bit 7 pkgtyp: this read-only bit indicates the CD1865 package type. this bit always reads back as . bit 6 regacken: enables register-based service-request acknowledgments. if this bit is a ? 0 ? , register-based acknowledgments are not accepted. in this case, the results of a read of any of the service-acknowledgment registers are undefined. this is the default state of regacken, and it ensures compatibility with earlier versions of the CD1865. when regacken is enabled, register-based acknowledges allow the user ? s software to acknowledge a service request by reading from a register rather than by driving the external ackin* signal. this is convenient in applications where interrupts are not supported or where polling is preferred. setting this bit does not disable the function of the ackin* signal. bit 5 daisyen: enables daisy-chaining of register-based service acknowledgments. when daisyen is a ? 1 ? , a CD1865 being addressed with a register-based service acknowledgment (a read occurs from a register- acknowledgment address) for which it has a pending request, places the contents of the global interrupt vector register modified by the service type on the data bus. when daisyen is a ? 1 ? , a CD1865 being addressed with a register-based service acknowledgment, for which it does not have a pending service request, asserts ackout* to pass the acknowledgment down the daisy chain. the next CD1865 in the chain monitors the acknowledgment as an ackin* acknowledgment. the service request acknowledge register addresses must be placed in the corresponding service match registers (, , and ) as part of the user setup for daisy-chaining of register-based service acknowledgments. if daisy-chaining of register-based service acknowledgments is not used, the service match registers may be programmed with any address codes that the user finds convenient for use with the ? normal ? ackin* service- acknowledge mechanism. if daisyen is a ? 0 ? and a CD1865 is addressed with a register-based service acknowledgment for which it does not have a pending service request, it responds by providing an interrupt vector with a modification code of ? 000 ? . the addressed CD1865 treats this as an interrupt acknowledge cycle, but with passing inhibited, it must ? take ? the acknowledge with an ack level of ? 00 ? (none of the interrupt types). regacken must be a ? 1 ? to enable register-based service acknowledgments. daisyen has no effect on daisy- chain operation of the regular ackin*/ackout* chain. bit 4 globpri: when autopri is used, if globpri is set to a ? 1 ? , the CD1865 prioritizes across multiple CD1865s sharing req () lines. if globpri is set to a ? 0 ? , the CD1865 accepts the acknowledge for the highest priority on- device interrupt. in both cases, automatic prioritizing is only done on type 1 (normally the modem signal change type) interrupt acknowledgments through the ackin* mechanism or the register-based acknowledge mechanism. when using globpri and autopri, it is possible to use the CD1865 with the three req lines wire-or ? ed together. in this configuration, with any interrupt request asserted, the global values of all requests appears asserted. globpri should be a ? 0 ? to force prioritization among the interrupt sources on-device. when no on- device interrupts are pending, the acknowledgment is subject to daisy-chaining. see daisyen description. bit 3 unfair: fairness override bit. if unfair is a ? 0 ? , normal fair share interrupt control is performed. if unfair is a ? 1 ? , the fair bits are all forced to a ? 1 ? , disabling the fair share mechanism. this is useful when the autopriority option is used, and the different req lines are wire-or ? ed together. bit 2 reserved. must be a ? 0 ? . bit 1 autopri: when set, indicates that the CD1865 should prioritize service requests in the manner selected by the prisel bit. in conjunction with the globpri bit, either local (within the device) or global (across daisy- chained devices) prioritization is done. with autopri set, auto-prioritization is performed only when a type 1 (modem) interrupt acknowledgment is recognized. acknowledgments of type 2 (transmit) and 3 (receive) interrupts continue to be unique and specific even with autopri set. this offers a form of local override to auto- prioritization for transmit or receive service request when continuing a second-priority service routine. if not set, the user must indicate the service request being acknowledged by the choice of service request acknowledge register. autopri x globpri => look at reqext to prioritize globally. autopri x globpri* => look at req to prioritize locally. bit 0 prisel: prioritized interrupt order option. if autopri is set, prisel selects the highest-priority service request. if prisel is a ? 0 ? , receive requests have the highest priority. if prisel is a ? 1 ? , transmit requests have the highest priority. modem signal change request priority is fixed at the lowest priority.
CD1865 ? intelligent eight-channel communications controller 100 datasheet 9.2.2.2 prescaler period registers (high/low) these two registers provide the initialization value for the timer prescaler that is clocked by the system clock. this establishes the clock for the various on-device timers. the value loaded into these registers must establish a clock period of at least 1.0 msec. for a clock speed of 33 mhz, the value must be 33,000 (decimal) or larger. the values in these registers are programmed to be ff (hex) automatically upon a hardware reset. 9.2.2.3 modem service match register this register must contain the value for modem signal change service requests that are presented on the address bus a0-a6 by the host to indicate the type of service request being acknowledged when ackin* is asserted. this register, along with the other two match registers, is compared to the value on the address bus during acknowledgment cycles so that the CD1865 can determine the service request being acknowledged by the host. bit 7 must be programmed to a ? 1 ? . the CD1865 compares all eight bits internally, but there are only seven address lines. bits 6:0 of the register are compared to a6:a0 of the address bus. bit 7 of the register is compared with a logic ? 1 ? . within any one CD1865, the three match registers must have unique values. in multiple CD1865 designs where service acknowledgments are cascaded, all match registers of the same type (for example, modem) must have the same value. register name: pprh register description: prescaler period register (high) default value: ff access: read/write 8-bit hex address: $70 intel hex address: $e0 motorola hex address: $e1 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 binary value register name: pprl register description: prescaler period register (low) default value: ff access: read/write 8-bit hex address: $71 intel hex address: $e2 motorola hex address: $e3 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 binary value register name: register description: modem service match register default value: 0 access: read/write 8-bit hex address: $61 intel hex address: $c2 motorola hex address: $c3 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 binary value
intelligent eight-channel communications controller ? CD1865 datasheet 101 in designs using register-based service acknowledgments (rrar, trar, and mrar), the addresses of these registers must be placed in the equivalent match register so that contains $75. 9.2.2.4 transmit service match register this register must contain the value for transmit data service requests that are presented on the address bus a0-a6 by the host to indicate the type of service request being acknowledged when ackin* is asserted. this register, along with the other two match registers, is compared to the value on the address bus during acknowledgment cycles so that the CD1865 can determine the service request being acknowledged by the host. bit 7 must be programmed to a ? 1 ? . the CD1865 compares all eight bits internally, but there are only seven address lines. bits 6:0 of the register are compared to a6:a0 of the address bus. bit 7 of the register is compared with a logic ? 1 ? . within any one CD1865, the three match registers must have unique values. in multiple-CD1865 designs where service acknowledgments are cascaded, all match registers of the same type (for example, transmit) must have the same value. in designs using register-based service acknowledgments (rrar, trar, and mrar), the addresses of these registers must be placed in the equivalent match register so that contains $76. 9.2.2.5 receive service match register this register must contain the value for receive data service requests that are presented on the address bus a0-a6 by the host to indicate the type of service request being acknowledged when ackin* is asserted. this register, along with the other two match registers, is compared to the value on the address bus during acknowledgment cycles so that the CD1865 can determine the service request being acknowledged by the host. bit 7 must be programmed to a ? 1 ? . the CD1865 compares all eight bits internally, but there are only seven address lines. bits 6:0 of the register are compared to a6:a0 of the address bus. bit 7 of the register is compared with a logic ? 1 ? . register name: register description: transmit service match register default value: 0 access: read/write 8-bit hex address: $62 intel hex address: $c4 motorola hex address: $c5 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 1 binary value register name: register description: receive service match register default value: 0 access: read/write 8-bit hex address: $63 intel hex address: $c6 motorola hex address: $c7 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 1 binary value
CD1865 ? intelligent eight-channel communications controller 102 datasheet within any one CD1865, the three match registers must have unique values. in multiple CD1865 designs where service acknowledgments are cascaded, all match registers of the same type (for example, receive) must have the same value. in designs using register-based service acknowledgments (rrar, trar, and mrar), the addresses of these registers must be placed in the equivalent match register so that contains $77. 9.2.2.6 global vector register register name: register description: global service vector register default value: ff access: read/write 8-bit hex address: $40 intel hex address: $80 motorola hex address: $81 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 binary value it2 it1 it0 bit description bits 7:3 these bits are user-defined. however, in a multiple-device design, these five bits must have a unique value in each CD1865 to identify which CD1865 is returning a vector during service acknowledgments. when writing to this register, write eight bits at once; the CD1865 modifies the low-three bits automatically. note that if this register is read in a normal manner, the original eight bits are read and the modified bits from the last acknowledgment cycle is not preserved. bits 2:0 these three bits indicate the group/type of service request occurring. these bit are supplied by the CD1865 during an acknowledgment cycle. note: * this code is returned by the CD1865 only when regacken is set, and daisyen is not set. in this condition, the CD1865 must provide a vector when acknowledged. if the CD1865 receives an acknowledgment for which it does not have a request pending, it returns ? 000 ? . it2 it1 it0 value group/type 0 0 0 0 no request pending* 0 0 1 1 modem signal change service request 0 1 0 2 transmit data service request 0 1 1 3 receive good data service request 1 0 0 4 reserved 1 0 1 5 reserved 1 1 0 6 reserved 111 7 receive exception service request
intelligent eight-channel communications controller ? CD1865 datasheet 103 9.2.3 service request/interrupt control registers 9.2.3.1 service request status register the i-level bits, ilv[1] and ilv[0], are the current context code from the service request context stack. they are encoded as follows: register name: register description: service request status register default value: 0 access: read only 8-bit hex address: $65 intel hex address: $ca motorola hex address: $cb bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 ilv[1] ilv[0] ext int ext int ext int
CD1865 ? intelligent eight-channel communications controller 104 datasheet bit description bits 7:6 . an accepted interrupt acknowledge cycle pushes a new context onto the stack. note: the status bits are positive true, and the * pins are negative true. the ? ...int ? (internal) values are local to the device being read, and the ? ...ext ? (external) values are the current external status on the pin, that is, the result of the wire-or ? ed function. bits 5:4 . bits 3:2 . bits 1:0 . ilv1 ilv0 context 0 0 not in a service request context 0 1 CD1865 is in a receive service request context 1 1 CD1865 is in a transmit service request context 1 0 CD1865 is in a modem service request context rreqext rreqint context 0 0 no interrupts 0 1 invalid state 1 1 the location device requests a receive interrupt. 10 external interrupt pending. the local device has no receive interrupts. treqext treqint context 0 0 no interrupts 0 1 invalid state 1 1 the location device requests a transmit interrupt. 10 external interrupt pending. the local device has no transmit interrupts. mreqext mreqint context 0 0 no interrupts 0 1 invalid state 1 1 the location device requests a modem interrupt. 10 external interrupt pending. the local device has no modem interrupts.
intelligent eight-channel communications controller ? CD1865 datasheet 105 9.2.3.2 modem request acknowledge register\ 9.2.3.3 transmit request acknowledge register 9.2.3.4 receive request acknowledge register the service request acknowledge registers are read-only registers that return an appropriate interrupt vector when read. reading one of these registers has the effect of a service acknowledgment cycle in the CD1865 (not necessarily the one addressed; it may be one further down the daisy chain). the vector supplied on the data bus during the cycle is described under the global service vector register description. regacken must be set for these registers to operate properly. register name: register description: modem request acknowledge register default value: 80 access: read only 8-bit hex address: $75 intel hex address: $ea motorola hex address: $eb bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 modified interrupt vector provided on read register name: register description: transmit request acknowledge register default value: 80 access: read only 8-bit hex address: $76 intel hex address: $ec motorola hex address: $ed bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 modified interrupt vector provided on read register name: register description: receive request acknowledge register default value: 80 access: read only 8-bit hex address: $77 intel hex address: $ee motorola hex address: $ef bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 modified interrupt vector provided on read
CD1865 ? intelligent eight-channel communications controller 106 datasheet 9.2.3.5 global channel registers 1 9.2.3.6 global channel registers 2 9.2.3.7 global channel registers 3 there are three registers used to provide the channel number of the channel requesting service. reading any of these registers causes the CD1865 to ? mask-in ? three bits, specifying the channel number of the currently active channel. normally these registers are read by the host when it is handling a service request. in this case, the three bits are the number of the channel requesting service. if any of the three registers are read when the CD1865 is not in a service request context, the three bits are the current value in the car. bits 4:2 are masked into the contents of this register by the CD1865 when it is read by the host. the actual contents of the register are not modified. these three registers are provided as a convenience to the user. in most applications, the user uses one of these locations, and sets the register to an arbitrary value. all types of service routines would use this register. however, in some cases it may be useful to be able to record information about the state of the CD1865 (or the software driving it) that is associated with each of the three service request types. in this case, the user may associate an individual register with each level of service request, and store whatever information is required in the unused bits. when entering a service routine, the software can check these bits (a sub-vector) to read recorded states. register name: register description: global service channel register 1 default value: 0 access: read/write 8-bit hex address: $41 intel hex address: $82 motorola hex address: $83 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 binary value c2 c1 c0 binary value register name: register description: global service channel register 2 default value: 0 access: read/write 8-bit hex address: $42 intel hex address: $84 motorola hex address: $85 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 binary value c2 c1 c0 binary value register name: register description: global service channel register 3 default value: 0 access: read/write 8-bit hex address: $43 intel hex address: $86 motorola hex address: $87 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 binary value c2 c1 c0 binary value
intelligent eight-channel communications controller ? CD1865 datasheet 107 9.2.3.8 channel access register this register contains the channel number used for channel-oriented host read or write operations when the host is not in a service request service routine. when the CD1865 and the host are in a service request routine, the CD1865 supplies the service-requesting channel number by the global interrupting channel register. the channel access register contents are not used during service request. the host service request routine is restricted to accessing only the register set of the service-requesting channel and the global registers. the channel access register is used by the host when the host is setting up or modifying the configuration of the channel. it is also used to issue certain channel-specific commands such as sending a flow-control character. bit description bits 7:5 user-defined bits 4:2 defines the service requesting channel number. bits 1:0 user-defined register name: register description: channel access register default value: 0 access: read/write 8-bit hex address: $64 intel hex address: $c8 motorola hex address: $c9 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 reserved a7(0)c2c1c0 c2 c1 c0 channel number 0 0 0 channel 0 0 0 1 channel 1 0 1 0 channel 2 0 1 1 channel 3 1 0 0 channel 4 1 0 1 channel 5 1 1 0 channel 6 1 1 1 channel 7
CD1865 ? intelligent eight-channel communications controller 108 datasheet 9.3 indexed indirect registers certain registers are specially designed to facilitate service-request handling. these registers do not exist as distinct registers, and can be thought of as pointers. these registers provide functions that are valid only during service-request service routines, and they must not be accessed at other times. three of the registers are actually pointers to the transmit and receive fifos, that is, when referenced they cause the appropriate fifo to be accessed. these registers are: receive data register, receive character status register, and transmit data register. the CD1865 maintains all channel-specific information. during data transfer between the host and the CD1865, the CD1865 uses a context-switching technique to switch the proper channel-specific information into the global registers for use by the host. this reduces the processing burden on the host by eliminating the need to calculate address offsets. 9.3.1 receive data count register bit description bits 7:4 reserved, must be a ? 0 ? . bit 3 internally, to the CD1865, this is address bit 7. this bit completes the external to internal CD1865 register address mapping, but it is only to be used for test purposes. in normal operation, this bit should always be a ? 0 ? . bits 2:0 channel number c2 c1 c0 channel number 0 0 0 channel 0 0 0 1 channel 1 0 1 0 channel 2 0 1 1 channel 3 1 0 0 channel 4 1 0 1 channel 5 1 1 0 channel 6 1 1 1 channel 7 register name: register description: receive data count register default value: 0 access: read only 8-bit hex address: $07 intel hex address: $0e motorola hex address: $0f bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 0 0 0 0 ct3 ct2 ct1 ct0
intelligent eight-channel communications controller ? CD1865 datasheet 109 9.3.2 receive data register this register accesses the receive data fifo for the channel. it is used by all channels to transfer receive fifo data to the host. successive reads transfer bytes from the fifo to the host. reading this register increments an internal pointer to the data and status fifos. during service-request routines for good data, this is the only register that must be read. during service-request routines for receive exception, the receive status register must be read first, then this register may be read. if both the rcsr and this register are to be read, the rcsr must be read first because reading this register causes the fifos to ? pop ? . any attempt to write to this register causes unpredictable results. bit description bits 7:4 reserved, must be a ? 0 ? . bits 3:0 specifies the number of good data bytes for transfer from the receive fifo at the time of service request. this may be larger or smaller than the threshold level set by the user. this register reflects the actual amount of data available, which can be greater than the threshold level if service-request response is slow, or less than the threshold if some other event (such as an error condition) has caused the receive good data interrupt. this register need only be read when receiving good data; by default all exceptions are one character, and the value in this register during a receive exception is not defined or meaningful. the rdcr contains a zero if the current service request is for the nndt case. register name: register description: receive data register default value: 0 access: read only 8-bit hex address: $78 intel hex address: $f0 motorola hex address: $f1 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 d7 d6 d5 d4 d3 d2 d1 d0 c3 c2 c1 c0 number of good bytes 0 0 0 0 does not occur 00011 00102 001 13 01004 01015 01106 01117 10008 1001 to 1111 does not occur
CD1865 ? intelligent eight-channel communications controller 110 datasheet 9.3.3 receive character status register this register accesses the status information for the current receive character. multiple errors in 1 byte are possible because the CD1865 evaluates the character bit-by-bit as it receives it. for example, a parity error is detected and flagged before a framing error. if a character is received with every bit (including the stop bit) equal to a ? 0 ? , it is marked as a line-break. if some bits are a ? 1 ? , but the stop bit is ? missing ? a ? 0 ? , it is marked as a framing error. if odd parity is set and the bits received are all zeroes, it is marked as both a break character and a parity error. in addition to any other bits, the overrun bit is set if an overrun has occurred. any attempt to write to this register causes unpredictable results. register name: register description: receive character status register default value: 0 access: read only 8-bit hex address: $7a intel hex address: $f4 motorola hex address: $f5 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 time-out sc det2 sc det1 sc det0 break pe fe oe bit description bit 7 time-out: indicates that the receive fifo is empty, and no data has been received within the receive time- out period. there is no data character associated with this status and no other status bits are valid if the time- out bit is set. must be ? armed ? by the nndt bit in . bits 6:4 special character detect (scd0-2): note: no special-character match is performed if any type of error occurs. the second character of a two- character sequence cannot cause a receiver overrun. bit 3 break: indicates that a break has been detected. bit 2 parity error: indicates that a parity error has been detected. bit 1 framing error: indicates that a bad stop bit has been detected. bit 0 overrun error: indicates that new data has arrived but the CD1865 fifo and holding registers are full. the new data is lost and the overrun indication is flagged on the last character received before the overrun occurred. scd2 scd1 scd0 status 0 0 0 none detected 001 special character 1 or special character 1 and 3 sequence matched (only if special character 1 and 3 sequence is enabled). 010 special character 2 or special character 2 and 4 sequence matched (only if special character 1 and 3 sequence is enabled). 011 special character 3 (only if special character 1 and 3 sequence is not enabled). 100 special character 4 (only if special character 2 and 4 sequence is not enabled).
intelligent eight-channel communications controller ? CD1865 datasheet 111 9.3.4 transmit data register when servicing a transmit data service request, the transmit data register accesses the transmit fifo of the service-requesting channel. data is written to the transmit data register by the host; the CD1865 automatic fifo pointer mechanism places the data into the service-requesting channel ? s transmit character fifo. up to 8 bytes of data may be written into the tdr during transmit data service request. any attempt to read from this register causes unpredictable results. 9.3.5 end-of-service request register this is a dummy register, and must be written to by the host ? s service request routine to signal to the CD1865 that the current service-request service is concluded. this must be the last access to the CD1865 during a service-request routine. writing to this register generates an internal end of service signal, which ? pops ? the CD1865 ? s service-request-context stack, allowing the CD1865 to resume normal processing and also service other channels. service-request contexts may be nested, as explained in section 5.4 ; that is, one can respond to and service a higher-priority event while in the middle of a lower-priority service request routine (nesting subroutine calls within other subroutines). any attempt to read from this register causes unpredictable results. 9.4 channel registers there are eight sets of channel registers, but only one set is available at any given time. this offers the software-simplifying advantage that a given register is at the same address regardless of the channel number. to access a given channel ? s registers, first point to them by writing the channel number to the channel access register. register name: register description: transmit data register default value: 0 access: write only 8-bit hex address: $7b intel hex address: $f6 motorola hex address: $f7 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 d7 d6 d5 d4 d3 d2 d1 d0 register name: register description: end-of-service request register default value: 0 access: write only 8-bit hex address: $7f intel hex address: $fe motorola hex address: $ff bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 irrelevant value
CD1865 ? intelligent eight-channel communications controller 112 datasheet 9.4.1 enable register a ? 1 ? in each bit position enables service request generation for the associated cause. 9.4.2 channel command register register name: register description: service request enable register default value: 0 access: read/write 8-bit hex address: $02 intel hex address: $04 motorola hex address: $05 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 dsr cd cts rxd rxsc txrdy txmpty nndt bit description bit 7 data-set-ready (dsr) service request: when enabled, generates a modem-change service request on the selected level changes of the dsr input. bit 6 carrier detect (cd) service request: when enabled, generates a modem-change service request on the selected level changes of the cd input. bit 5 clear-to-send (cts) service request: when enabled, generates a modem-change service request on the selected level changes of the cts input. bit 4 receive data service request: when enabled, the receive data service request is generated for receive data and receive exceptions. bit 3 receive special character (rxsc) service request: when enabled, the receive data exception service request is generated when a received character matches one of the four user-defined special characters. when disabled, receive exceptions are generated for error conditions and time-outs only. if flow-control transparency is set, flow-control characters are stripped, and no receive special character exceptions occurs. bit 2 transmit ready (txrdy) service request: when enabled, the transmitter generates a service request when the transmit fifo becomes empty. set this bit when first beginning transmission on a channel, and before attempting to write data to the transmit fifo. enabling the service request causes an immediate transmit service request, allowing it to write data into the transmit fifo in the usual manner. this bit may be set and cleared as needed to regulate the assertion of transmit data service requests on each channel. this technique is preferred over disabling the transmitter. bit 1 transmitter empty (txmpty) service request: when enabled, a service request is generated when the transmit fifo, the transmit holding register, and the transmit shift register are all empty. this mode is provided to allow the host to determine when all bits are sent and it is safe to alter a channel ? s configuration. bit 0 no new data time-out (nndt) service request: when enabled, a receive exception service request is generated after the completion of data transfer from the CD1865 to the host. this feature assists in buffer management by providing a notice of a gap in the receive data stream longer than the time-out period. register name: register description: channel command register default value: 0 access: read/write 8-bit hex address: $01 intel hex address: $02 motorola hex address: $03 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 reset chan cor chng send sp ch chan ctl d3 d2 d1 d0
intelligent eight-channel communications controller ? CD1865 datasheet 113 the ccr is a special register used to prompt the CD1865 processor to indicate if any channel parameters have changed. bits are set in the ccr to indicate which of several commands to carry out. the CD1865 processor notes changes in these bits and makes the required adjustments to the hardware; this process can take from microseconds to milliseconds. therefore, it is important that the host cpu waits until the CD1865 processor has finished the current command before issuing any more commands, or continuing with any operation that the command affects. for example, after setting the local loopback bit in cor2, the host must wait until the command is complete before resuming transmission. if the host does not wait, characters may not be properly looped back. reset channel, channel option, send special character, and channel control commands can be set through the ccr register. one of the four commands can be selected by setting the appropriate bit (7:4). the commands can be defined in detail by setting the bit fields (3:0) accordingly. bit fields (3:0) are defined differently by each command. the CD1865 indicates completion by clearing the ccr. the tables on the following pages define the appropriate setting of the bits according to the command. reset channel command this is a software reset command. there are two types of reset ? channel reset (type 0), which resets only the current channel, and global reset (type 1), which resets the entire part to its power- up condition. when the channel reset command is issued, the CD1865 disables the transmitter and the receiver and clears the data and status fifos of the channel. channel parameters are not affected by a channel reset. bit description bit 7 reset channel command. bit 6 channel option register command. bit 5 send special character(s) command. bit 4 channel control command. bits 3:0 defined by the type of command being issued; see the following descriptions. bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 reset chan000000type bit description bit 7 reset channel command, must be a ? 1 ? . bits 6:1 not used. must be a ? 0 ? . bit 0 reset type: if the reset type bit is a ? 0 ? , a software reset of the channel is performed. the transmitter and receiver are disabled, and all fifos are cleared (flushed). if the reset type bit is a ? 1 ? , an on-device firmware initialization of all channels is performed. all channel and global parameters are reset to their power-on reset condition.
CD1865 ? intelligent eight-channel communications controller 114 datasheet channel option register change command changes made to some channel option register bits must be signalled to the CD1865 by this command. any combination of cor changes may be indicated by one command. all of the bits in cor3 take effect immediately, and all of the bits in cor2 (except llm) take effect immediately. in other words, when changing cor3 or any of cor2 (except llm), it is not necessary to issue a channel option register change command. however, to preserve compatibility with older CD1865 designs, it is acceptable to set these bits. send special character(s) command bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 0 cor chng 0 0 cor3 cor2 cor1 n/u bit description bit 7 must be a ? 0 ? . bit 6 channel option register change command, must be a ? 1 ? . bits 5:4 must be a ? 0 ? . bit 3 channel option register 3 changed (no longer required). bit 2 channel option register 2 changed (required only for local loopback mode change). bit 1 channel option register 1 changed. bit 0 not used. bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 0 0 send sp ch 0 0 sspc2 sspc1 sspc0 bit description bits 7:6 must be a ? 0 ? .
intelligent eight-channel communications controller ? CD1865 datasheet 115 channel control command when turning the receiver or transmitter on or off, it is faster to simply enable and disable service requests () rather than using the channel control command. bit 5 send special character(s) command, must be a ? 1 ? . bits 4:3 must be a ? 0 ? . bits 2:0 special character select bit description sspc2 sspc1 sspc0 function 0 0 0 do not use 001 send special character 1, or characters 1 and 3 in sequence if cor3 [xonch] defines a two-character sequence. 0 1 0 send special character 2, or characters 2 and 4 in sequence if cor3 [xoffch] defines a two-character sequence. 0 1 1 send special character 3 1 0 0 send special character 4 1 0 1 do not use 1 1 0 do not use 1 1 1 do not use bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 0 0 0 chan ctl xmtr en xmtr dis rcvr en rcvr dis bit description bits 7:5 must be a ? 0 ? . bit 4 channel control command, must be a ? 1 ? . bit 3 transmitter enable bit 2 transmitter disable bit 1 receiver enable bit 0 receiver disable
CD1865 ? intelligent eight-channel communications controller 116 datasheet 9.4.3 channel option register 1 changes to this register must be signalled by the channel command register . 9.4.4 channel option register 2 changes only to bit 4 (llm) of this register must be signalled by the channel command register. register name: cor1 register description: channel option register 1 default value: 0 access: read/write 8-bit hex address: $03 intel hex address: $06 motorola hex address: $07 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 parity parm1 parm0 ignore stop 1 stop 0 chl 1 chl 0 bit description bit 7 parity: 1 = odd parity. 0 = even parity. bits 6:5 parity mode 1 and 0: defines parity mode for both the transmitter and the receiver. parm1 parm0 parity 0 0 no parity 0 1 force parity (odd parity = force 1, even = force 0) 1 0 normal parity 1 1 not used bit 4 ignore: ignore parity 0 = evaluate parity on received characters. 1 = do not evaluate parity on received characters. bits 3:2 stop bit length: specifies the length of the stop bit. stop1 stop0 stop bit 0 0 1 stop bit 0 1 1 1/2 stop bits 1 0 2 stop bits 1 1 2 1/2 stop bits bits 1:0 character length: chl1 chl0 character length 0 0 5 bits 0 1 6 bits 1 0 7 bits 1 1 8 bits register name: cor2 register description: channel option register 2 default value: 0 access: read/write 8-bit hex address: $04 intel hex address: $08 motorola hex address: $09 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 ixm txibe etc llm rlm rtsao ctsae dsrae
intelligent eight-channel communications controller ? CD1865 datasheet 117 9.4.5 channel option register 3 changes to this register do not have to be signalled by the ccr. bit description bit 7 implied xon mode (ixm): this bit has meaning only when in the automatic transmit in-band flow-control mode. during transmit in-band flow-control mode, the CD1865 stops transmission upon detection of an xoff character or character sequence. the ixm bit determines whether the CD1865 should restart transmission based on receipt of an xon character or any character. when ixm bit is set, the CD1865 restarts transmission upon detection of any character. when ixm bit is not set, the CD1865 waits for the xon character or character sequence to restart the transmission. bit 6 transmit in-band (xon/xoff) flow control automatic enable (txibe): the CD1865 in the transmitting mode is flow-controlled by the remote. upon receipt of the xoff character, the CD1865 terminates transmission after the current character in the transmit shift register, and the character in the transmit holding register is sent. the CD1865 resumes transmission upon receipt of the xon character, or any character, depending on the state of the ixm bit. bit 5 embedded transmitter command enable (etc): if set, the embedded special transmitter command functions are enabled. bit 4 local loopback mode (llm): 1 = enables the local loopback mode. 0 = disables the local loopback mode. bit 3 remote loopback mode (rlm): 1 = enables the remote loopback mode. 0 = disables the remote loopback mode. bit 2 rts automatic output enable (rtsao): when set, if the channel is enabled, the CD1865 automatically asserts the rts* output when it has characters to send. if ctsae is also set, it waits for cts* to respond prior to transmission. bit 1 cts automatic enable (ctsae): enables the cts* input to be used as automatic transmitter enable or disable. bit 0 dsr automatic enable (dsrae): enables the dsr* input as automatic receiver enable or disable. register name: cor3 register description: channel option register 3 default value: 0 access: read/write 8-bit hex address: $05 intel hex address: $0a motorola hex address: $0b bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 xon ch xoff ch fct scde rxth3 rxth2 rxth1 rxth0
CD1865 ? intelligent eight-channel communications controller 118 datasheet 9.4.6 channel control status register this status register stores the current state of the channel. it may be read by the host at any time. if the host determines that a flow-control state is inappropriate, it may be cleared by enabling or disabling the transmitter or receiver by ccr command. bit description bit 7 xon character definition: 0 = xon character is a single-character code, and it is defined by special character. 1 = xon character is a double-character sequence, and it is defined by special characters 1 and 3. bit 6 xoff character definition: 0 = xoff character is a single-character code, and it is defined by special character 2. 1 = xoff character is a double-character sequence, and it is defined by special characters 2 and 4. bit 5 flow-control transparency (fct) mode: 0 = flow-control characters received are given to the host by receive exception service requests. 1 = flow-control characters received are not given to the host by receive exception service requests. bit 4 special-character detection enable: 0 = special-character status detection is disabled. 1 = special-character status detection is enabled. bits 3:0 rxfifo threshold: register name: ccsr register description: channel control status register default value: 0 access: read only 8-bit hex address: $06 intel hex address: $0c motorola hex address: $0d bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 rxen rxfloff rxflon n/u txen txfloff txflon n/u rxth3 rxth2 rxth1 rxth0 status 0000do not use 00011 character 00102 characters 00113 characters 01004 characters 01015 characters 01106 characters 01117 characters 10008 characters 1001 to 1111 reserved, do not use.
intelligent eight-channel communications controller ? CD1865 datasheet 119 9.4.7 receiver bit register this register monitors certain functions of the actual receive hardware. it should never be written to as this causes the CD1865 to fail. only two of the bits are defined herein; however, the other bit positions can change value, so these bits should be ? masked-out ? before testing. bit 6 is the sampled state of the rxd pin, as sampled at the last bit-rate clock edge. this is not the actual rxd input, as rxd cannot be sampled in real time. if no data has been received for a period of time, this bit still reflects the last sampled state of the line at the end of the last character. this is because the line is not sampled when the CD1865 is looking for the start bit of a new character. bit description bit 7 rxen receiver enable: 0 = receiver is disabled. 1 = receiver is enabled. bit 6 rxfloff receive flow-off: 0 = normal 1 = the CD1865 has requested the remote to stop transmission (send xoff command has been given to the channel). this bit is reset when the CD1865 has requested the remote to restart transmission, or when the receiver is enabled or disabled, or when the channel is reset. bit 5 rxflon receive flow-on: 0 = normal 1 = the CD1865 has requested the remote to restart character transmission (send xon command has been given to the channel). this bit is reset when the next (non-flow control) character is received, or when the receiver is enabled or disabled, or when the channel is reset. bit 4 not used bit 3 txen transmitter enable: 0 = transmitter is disabled. 1 = transmitter is enabled. bit 2 txfloff transmit flow-off: 0 = normal 1 = the CD1865 has been requested by the remote to stop transmission. this bit is reset when the CD1865 receives a request to resume transmission, or when the transmitter is enabled or disabled, or when the channel is reset. bit 1 txflon transmit flow-on: 0 = normal 1 = the CD1865 has been requested by the remote to resume transmission. this bit is reset once character transmission is resumed, or when the transmitter is enabled or disabled, or when the channel is reset. bit 0 not used register name: rbr register description: receiver bit register default value: 21 access: read only 8-bit hex address: $33 intel hex address: $66 motorola hex address: $67 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 reserved rxd start hunt reserved
CD1865 ? intelligent eight-channel communications controller 120 datasheet bit 5 indicates whether the CD1865 is looking for a start bit. if bit 5 is a ? 1 ? , it is looking. if bit 5 is a ? 0 ? , it is receiving a character. 9.4.8 receive time-out period register this register defines the time period for two functions related to the receive fifo. as each character is moved to the receive fifo, the receive timer is reloaded with the receive data time-out period. the receive timer is then decremental on each tick of the prescaler counter. if the receive timer reaches a ? 0 ? , it causes a receive good data service request. there is another optional feature called no new data time-out. when enabled, the receive timer generates a receive exception if the timer expires after the last data is transferred from the fifo to the host. this is intended to tell the host that no more data is arriving, and to go ahead and process the buffer. the receive time-out period register defines the time-out period for both of these functions. it counts in time increments defined by the prescaler. 9.4.9 receive bit rate period registers (high/low) register name: rtpr register description: receive time-out period register default value: 5 access: read/write 8-bit hex address: $18 intel hex address: $30 motorola hex address: $31 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 receiver data time-out period register name: rbprh register description: receive bit rate period register (high) default value: 0 access: read/write 8-bit hex address: $31 intel hex address: $62 motorola hex address: $63 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 receiver bit rate divisor byte register name: rbprl register description: receive bit rate period register (low) default value: 0 access: read/write 8-bit hex address: $32 intel hex address: $64 motorola hex address: $65 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 receiver bit rate divisor byte
intelligent eight-channel communications controller ? CD1865 datasheet 121 these two registers contain the 16-bit pre-load value for the receive bit rate counter. this count establishes the basic receiver clock rate, which must be 16 times the required receiver bit rate. these registers are reset to a ? 0 ? by reset*. the period established for the 16 times receiver clock rate is equal to the rbpr 16-bit binary value times the system clock (clk) period. 9.4.10 transmit bit rate period registers (high/low) these two registers contain the 16-bit pre-load value for the transmit bit rate counter. this count establishes the transmitter clock rate, which must be 16 times the required transmitter bit rate. the precise period established for the 16 times transmitter clock is equal to the rbpr 16-bit binary value times the system clock (clk) period. these registers are reset to a ? 0 ? by reset*. 9.4.11 special character register 1 this register stores the right-justified bit pattern for special character 1. unused bits must be a ? 0 ? . during receive, this character is one of the four characters compared with the received data for special-character recognition. if a match occurs with one of these four characters, it is noted in the receiver status fifo entry accompanying the received character unless a double-character compare is enabled. in this case, the receive status fifo entry is not made until both characters are compared and matched. during transmit, this register contains the characters that are sent as a result of the send special character 1 command. if two-character sequences are enabled, characters 1 and 3 are sent. register name: tbprh register description: transmit bit rate period register (high) default value: 0 access: read/write 8-bit hex address: $39 intel hex address: $72 motorola hex address: $73 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit bit rate divisor byte register name: tbprl register description: transmit bit rate period register (low) default value: 0 access: read/write 8-bit hex address: $3a intel hex address: $74 motorola hex address: $75 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 transmit bit rate divisor byte register name: schr1 register description: special character register 1 default value: 0 access: read/write 8-bit hex address: $09 intel hex address: $12 motorola hex address: $13 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 special character 1
CD1865 ? intelligent eight-channel communications controller 122 datasheet special character 1 defines the xon character or the first-half of the xon-character sequence. the second half is special character register 3. 9.4.12 special character register 2 this register stores the right-justified bit pattern for special character 2. unused bits must be a ? 0 ? . during receive, this character is one of the four characters compared with the received data for special-character recognition. if a match occurs with one of these four characters, it is noted in the receiver status fifo entry accompanying the received character unless a double-character compare is enabled. in this case, the receive status fifo entry is not made until both characters are compared. during transmit, this register contains the characters that are sent as a result of the send special character 2 command. if two-character sequences are enabled, characters 2 and 4 are sent. special character 2 defines the xoff character or the first-half of the xoff-character sequence. 9.4.13 special character register 3 this register stores the right-justified bit pattern for special character 3. unused bits must be a ? 0 ? . during receive, this character is one of the four characters compared with the received data for special character recognition. if a match occurs with one of these four characters, it is noted in the receiver status fifo entry accompanying the received character unless a double-character compare is enabled. in this case, the receive status fifo entry is not made until both characters are compared. during transmit, this register contains the characters that are sent as a result of the send special character 3 command. special character 3 may be the second-half of the xon-character sequence. register name: schr2 register description: special character register 2 default value: 0 access: read/write 8-bit hex address: $0a intel hex address: $14 motorola hex address: $15 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 special character 2 register name: schr3 register description: special character register 3 default value: 0 access: read/write 8-bit hex address: $0b intel hex address: $16 motorola hex address: $17 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 special character 3
intelligent eight-channel communications controller ? CD1865 datasheet 123 9.4.14 special character register 4 this register stores the right-justified bit pattern for special character 4. unused bits must be a ? 0 ? . during receive, this character is one of the four characters compared with the received data for special character recognition. if a match occurs with one of these four characters, it is noted in the receiver status fifo entry accompanying the received character unless a double-character compare is enabled. in this case, the receive status fifo entry is not made until both characters are compared. during transmit, this register contains the characters that are sent as a result of the send special character 4 command. special character 4 may be the second-half of the xoff-character sequence. 9.4.15 modem change register the CD1865 sets bits in this register when it recognizes a level change on a modem pin, as programmed by the modem change option registers. changes detected are a cause for asserting the modem service request if corresponding service request enable bits are set. once the service request is asserted, updates to this register are inhibited until end of register () is written at the end of the modem service request routine. the host must clear these register bits during the service routine. register name: schr4 register description: special character register 4 default value: 0 access: read/write 8-bit hex address: $0c intel hex address: $18 motorola hex address: $19 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 special character 4 register name: mcr register description: modem change register default value: 0 access: read/write 8-bit hex address: $12 intel hex address: $24 motorola hex address: $25 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 dsrchg cdchg ctschg 0 0 0 0 0 bit description bit 7 dsr changed: a logic ? 1 ? denotes that the data-set-ready input has changed state. bit 6 cd changed: a logic ? 1 ? denotes that the carrier detect input has changed state. bit 5 cts changed: a logic ? 1 ? denotes that the clear-to-send input has changed state. bits 4:0 must be a ? 0 ? .
CD1865 ? intelligent eight-channel communications controller 124 datasheet 9.4.16 modem change option register 1 this register is used to define the current state change options to be monitored. register name: mcor1 register description: modem change option register 1 default value: 0 access: read/write 8-bit hex address: $10 intel hex address: $20 motorola hex address: $21 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 dsrzd cdzd ctszd 0 dtrth3 dtrth2 dtrth1 dtrth0 bit description bit 7 dsrzd is a ? 1 ? : detect high-to-low voltage transition on dsr* input (zero-to-one transition of dsr (msvr) bit). bit 6 cdzd is a ? 1 ? : detect high-to-low voltage transition on cd* input (zero-to-one transition of cd (msvr) bit). bit 5 ctszd is a ? 1 ? : detect high-to-low voltage transition on cts* input (zero-to-one transition of cts (msvr) bit). bit 4 must be a ? 0 ? . bits 3:0 defines the threshold level that causes negation of dtr* when this flow-control option is specified. normally, this level should be equal to or higher than the service-request level threshold as set in cor3. if it is set lower than the service-request threshold, it defaults to the service-request threshold level. dtrth3 dtrth2 dtrth1 dtrth0 function 0000automatic dtr m ode disabled 00011 character 00102 character 00113 character 01004 character 01015 character 01106 character 01117 character 10008 character
intelligent eight-channel communications controller ? CD1865 datasheet 125 9.4.17 modem change option register 2 this register is used to define the current state change options to be monitored. 9.4.18 modem signal value register this register is read to determine the current input levels on the modem input pins. it is written to supply an output value for the rts* and dtr* pins. the register bits have the opposite polarities from the actual states on the individual pins. writing a ? 1 ? causes the pin to go to nominal zero volts. register name: mcor2 register description: modem change option register 2 default value: 0 access: read/write 8-bit hex address: $11 intel hex address: $22 motorola hex address: $23 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 dsrodcdodctsod00000 bit description bit 7 dsrod is a ? 1 ? : detect low-to-high transition on dsr* input (one-to-zero transition dsr (msvr) bit). bit 6 cdod is a ? 1 ? : detect low-to-high transition on cd* input (one-to-zero transition of cd (msvr) bit). bit 5 ctsod is a ? 1 ? : detect low-to-high transition on cts* input (one-to-zero transition of cts (msvr) bit). bits 4:0 must be a ? 0 ? . register name: msvr register description: modem signal value register default value: 0 access: read/write 8-bit hex address: $28 intel hex address: $50 motorola hex address: $51 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 dsr cd cts n/u n/u n/u dtr rts bit description bit 7 dsr: current state of data-set-ready input. bit 6 cd: current state of carrier detect input. bit 5 cts: current state of clear-to-send input. bits 4:2 not used. bit 1 dtr: current state of data-terminal-ready output. bit 0 rts: current state of request-to-send output.
CD1865 ? intelligent eight-channel communications controller 126 datasheet 9.4.19 modem signal value request-to-send register in the modem signal value register, a write to either rts or dtr affects the state of the other one. this can be a problem when the CD1865 is using one of these signals for flow control and the other one needs to be used under host control. this register writes to rts without affecting the state of any other bits. rts is at bit 0. 9.4.20 modem signal value data-terminal-ready register in the modem signal value register, a write to either rts or dtr affects the state of the other one. this can be a problem when the CD1865 is using one of these signals for flow control and the other one needs to be used under host control. this register writes to dtr without affecting the state of any other bits. dtr is at bit 1. note: before beginning any new design with this device, please contact intel for the latest errata information. see the back cover of this document for sales office locations and phone numbers. register name: msvrts register description: modem signal value request-to-send register default value: 0 access: write only 8-bit hex address: $29 intel hex address: $52 motorola hex address: $53 bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0 0000000rts register name: msvdtr register description: modem signal value data terminal ready default value: 0 access: write only 8-bit hex address: $2a intel hex address: $54 motorola hex address: $55 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 000000dtr0
intelligent eight-channel communications controller ? CD1865 datasheet 127 10.0 electrical specifications 10.1 absolute maximum ratings operating ambient temperature 0 c to 70 c storage temperature ? 65 c to 150 c all voltages, with respect to ground ? 0.5 volts to v cc + 0.5 volts supply voltage (v cc ) + 7.0 volts power dissipation 0.5 watt note: stress above those listed under absolute maximum ratings may cause permanent damage to the device. this is a stress rating only and functional operation of the device at these or any conditions above those indicated in the operational sections of this specification is not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. 10.2 recommended operating conditions supply voltage (v cc ) 5 volts 5% operating free-air ambient temperature 0 c < t a < 70 c system clock 33 mhz 10.3 dc electrical characteristics (@ v cc = 5 volts 5%, t a =0 c to 70 c symbol parameter min max units conditions v il input low voltage ? 0.5 0.8 v v ih input high voltage 2.0 v cc v v ol output low voltage 0.4 v i ol =8 ma v oh output high voltage 2.4 v cc vi oh = ? 8 ma i il input leakage current ? 10 10 a0 CD1865 ? intelligent eight-channel communications controller 128 datasheet 10.4 index of timing information 10.5 ac electrical characteristics internally, the CD1865 is a fully clocked design; however, the hardware interface to the CD1865 may be either unclocked or clocked. an unclocked interface is generally easier to implement, especially if the CD1865 and its host are operating at different clock speeds. a clocked interface may be faster in some applications. 10.5.1 clocked bus interface data transfers to or from the device occur in two steps. the first step occurs during the clock-low time. if the read/write state machine detects that it is time to do a cycle, it acquires the internal bus. the second step, that of actually transferring the data, occurs during the clock-high time. the cycle is complete at the end of the clock-high time. the read/write state machine determines that it is time to do a cycle when there is a falling edge on the clock and both cs* and ds* are low. there is a specified setup time which must be met to guarantee that the cycle begins. if this setup is not met, the cycle occurs one clock later. if the cycle is recognized, arbitration for the internal bus is done during the clock-low time. addresses (and data, if a write cycle) must meet another setup time specification to the rising edge of the clock for the actual data transfer to occur properly during the clock-high time. in addition, the addresses must remain valid throughout the clock-high time, as specified. if the cycle is a write cycle, data must remain valid as specified. if the cycle is a read cycle, data is guaranteed valid for a specified time after the rising edge of the clock. figure title page figure 29 ? clocked bus interface reset ? 130 figure 30 ? clocked bus interface clocks ? 131 figure 31 ? clocked bus interface read cycle, motorola ? -style handshake ? 131 figure 32 ? clocked bus interface service acknowledgment cycle, motorola ? -style handshake ? 132 figure 33 ? clocked bus interface write cycle, motorola ? -style handshake ? 133 figure 34 ? clocked bus interface read cycle, intel ? -style handshake ? 134 figure 35 ? clocked bus interface service acknowledgment cycle, intel ? -style handshake ? 135 figure 36 ? clocked bus interface write cycle, intel ? -style handshake ? 136 figure 37 ? unclocked bus interface read cycle, motorola ? -style handshake ? 139 figure 38 ? unclocked bus interface service acknowledgment cycle, motorola ? -style handshake ? 140 figure 39 ? unclocked bus interface write cycle, motorola ? -style handshake ? 141 figure 40 ? unclocked bus interface read cycle, intel ? -style handshake ? 142 figure 41 ? unclocked bus interface service acknowledgment cycle, intel ? -style handshake ? 143 figure 42 ? unclocked bus interface write cycle, intel ? -style handshake ? 144
intelligent eight-channel communications controller ? CD1865 datasheet 129 service acknowledge cycles are a special case of read cycles. the service acknowledge ? read ? (which returns the global service request vector value to the host) is started when the read/write state machine detects both ds* and another internal signal derived from both ackin* and ds*. there are two possible worst-case paths to consider when determining whether ds* and ackin* meet the necessary setup times to guarantee recognition on a particular clock edge. the longest path is ds*; it must propagate through a gate, an 8-bit comparator, a state machine, and another gate before arriving at the read/write state machine. the setup time for this is given in table 10 . the other critical path is ackin*; it must pass through a state machine and a gate before arriving at the read/write state machine. the setup time to guarantee recognition on a particular clock edge is given in table 10 . intel-style pin names are shown in {brackets}. all times are in nanoseconds, unless otherwise specified. table 10. clocked timings (sheet 1 of 2) number in figures description min (1) max (1) notes t 1 setup, ds*{rd*} and cs* low to clk low, for read or write cycle to start ( ? ordinary ? reads and all writes) 10 2 t 2 setup, ds* {rd*} low to clk low, for service acknowledge cycle to start (ackin* cycles and read cycles from acknowledge registers) 15 3 t 3 setup, ackin* low to clk low for cycle to start 10 t 4 setup, address valid to cs* and ds* low 3 t 5 setup, address valid to ds* (service acknowledge cycles) 4 4 t 6 setup, write data valid to clk high 0 t 7 setup, r/w* {rd*, wr*} stable to ds* and cs* low (read, write cycles) 0 2 , 5 t 8 (ds* and cs*), or (rd* and cs*), or (wr* and cs*), high 5 6 , 7 t 9 hold time, cs* low after clk high (read, write cycles) 5 8 t 10 hold time, ds* {rd*} after valid data 0 infinity 8 t 11 hold time, address valid after clk high 15 8 t 12 hold time, write data valid after clk high 10 t 13 hold time, ackin* low after next clk low 4 9 t 14 clock period (t clk ) 30 200 10 t 15 clock low time 12 10 t 16 clock high time 12 10 clock duty cycle (50% 10%) t 17 clock rise/fall time 3 11 t 18 reset pulse width (after power is good and clock is stable) 5 clock periods t 19 data bus out of hi-z after clk low 0 12 t 20 read data valid after clk high 35 t 21 ackin* to ackout* propagation delay 12 t 22 ackout* high after ackin* high 12 t 23 ds* {rd*} high to data bus three-state 0 10 t 24 dtack* assert after clk high (dtackdly = 0) 25 t 25 dtack* assert after clk low (dtackdly = 1) 20
CD1865 ? intelligent eight-channel communications controller 130 datasheet t 26 dtack* negate after ds* {rd* or wr*} negation 10 t 27 ackout* assert after cs* and ds* active on register acknowledge cycle with no match 22 13 t 28 dtack* active pull-up time 14 t 29 ackout* high after end of cycle 22 notes: 1. unless otherwise noted, all values are in nanoseconds (ns). 2. the reference to ds* and cs* refers to whichever one goes active last; that is, both signals must meet the setup time requirement. 3. enabling the register acknowledge ( ? regack ? ) feature changes the timing somewhat, even on cycles where ? regack ? is not being used. 4. calculated value; guaranteed by design, but not tested. 5. for motorola-style interface, refers to r/w*.for intel-style interface, refers to rd* or wr* (whichever is inactive for that cycle). 6. a cycle must positively end before another begins; that is, control signals shall return to states such that no cycle is pend ing or active. 7. guaranteed by design, but not tested. 8. during register based acknowledge cycles, these signals must be held in the correct state until valid data is presented by the device, as indicated by dtack* going active. note that in daisy-chain applications, the response from the chain may be quite long due to the ackin*-ackout* propagation delay required for the actual interrupting device to receive the select (ackin*). waiting for the active dtack* from the chain eliminates any timing problems relating to these parameters. 9. ackin* must be low for at least one clock period plus setup and hold times if there is only one CD1865 in the daisy chain. if there is more than one CD1865 in a daisy chain, ackin* must be low until it has rippled all the way down the chain. 10.when using the clock out (ckout) of one CD1865 to drive subsequent CD1865s (such as in daisy-chain environments), ckout is skewed (delayed) by 3 ns from the internal clock. therefore, on subsequent CD1865s, setup times are improved by 3 ns and hold times are derated by 3 ns. 11.for clock periods greater than 100 ns (10 mhz or less clock), rise and fall time may be 5 ns maximum. 12.greater than a ? 0 ? by design, but not tested. 13.this is the time for ackout* to assert on register acknowledge cycles. ackout* asserts if the device determines the acknowledgment is not intended for that part. if ackout* asserts, the device does not drive the data bus or assert dtack*. these functions are left to a device further down the daisy chain that accepts the acknowledge cycle. 14.dtack* sources current (drives ? high ? ) until the voltage on the dtack* line is approximately 1.5 volts. then dtack* goes to an ? open-drain ? (high-impedance) state. figure 29. clocked bus interface reset table 10. clocked timings (sheet 2 of 2) number in figures description min (1) max (1) notes v cc clk reset* t 18
intelligent eight-channel communications controller ? CD1865 datasheet 131 figure 30. clocked bus interface clocks figure 31. clocked bus interface read cycle, motorola ? -style handshake t 14 t 16 t 15 CD1865 clock ds* cs* r/w* address read data dtack* ackin* ackout* t 1 new cycle may begin don ? t care don ? t valid undefined valid t 8 t 7 t 11 t 19 t 20 t 23 t 24 t 25 t 26 t 28 t 27 t 10 t 4 care don ? t care t 29 t 9
CD1865 ? intelligent eight-channel communications controller 132 datasheet figure 32. clocked bus interface service acknowledgment cycle, motorola ? -style handshake CD1865 t 2 clock ds* cs* r/w* address read data dtack* ackin* ackout* t 5 new cycle may begin don ? t care don ? t care valid undefined t 8 t 19 t 20 t 23 t 24 t 26 t 28 t 13 t 3 t 21 t 10 valid t 7 t 8 t 22 t 25 t 11
intelligent eight-channel communications controller ? CD1865 datasheet 133 figure 33. clocked bus interface write cycle, motorola ? -style handshake CD1865 clock ds* cs* r/w* address write data dtack* ackin* ackout* t 1 new cycle may begin don ? t care don ? t valid t 8 t 9 t 7 t 11 t 12 t 24 t 25 t 26 t 28 t 4 care don ? t care don ? t care valid t 6 don ? t care
CD1865 ? intelligent eight-channel communications controller 134 datasheet figure 34. clocked bus interface read cycle, intel ? -style handshake CD1865 clock rd* cs* wr* address read data dtack* ackin* ackout* t 1 new cycle may begin don ? t care don ? t valid undefined valid t 9 t 7 t 11 t 19 t 20 t 23 t 24 t 25 t 26 t 28 t 27 t 4 care don ? t care t 8 t 10
intelligent eight-channel communications controller ? CD1865 datasheet 135 figure 35. clocked bus interface service acknowledgment cycle, intel ? -style handshake CD1865 t 2 clock rd* cs* wr* address read data dtack* ackin* t 5 don ? t care valid undefined t 8 t 19 t 20 t 23 t 24 t 25 t 26 t 28 t 13 t 3 t 10 don ? t care t 11 t 8 t 7 ackout* t 22 t 21 valid
CD1865 ? intelligent eight-channel communications controller 136 datasheet 10.5.2 unclocked bus interface unclocked timing diagrams represent worst-case synchronization delays. that is, they reflect the maximum number of clock cycles required to complete the operation. internally, the CD1865 fully synchronizes all signals; thus, the user need not be concerned with setup times or metastability. the vast majority of CD1865 designs employ an unclocked bus interface. figure 36. clocked bus interface write cycle, intel ? -style handshake CD1865 clock wr* cs* rd* address write data dtack* ackin* ackout* t 1 don ? t care don ? t valid t 8 t 9 t 7 t 11 t 12 t 24 t 25 t 26 t 28 t 4 care don ? t care don ? t care valid t 6 don ? t care
intelligent eight-channel communications controller ? CD1865 datasheet 137 all times are based on a master clock (clk) of 15 mhz. all times are measured in nanoseconds. intel-style handshake signals (where appropriate) are shown in {curly brackets}. table 11. unclocked timings (sheet 1 of 2) number description min1 max1 notes t 1 setup time, address to cs*, ds* {cs*, rd* or wr*} 3 2 t 2 setup time, r/w* to cs* or ds* 0 2 t 3 hold time, address after cs* or ds* {cs* or rd* or wr*} 0 3 , 4 t 4 r/w* hold time after cs* and ds* 3 3 , 4 t 5 delay time, dtack* assert to valid read data: if dtackdly = 0 if dtackdly = 1 25 -12 t 6 dtack* assert after cs* or ds* {rd*} or ackin* if dtackdly = 0 if dtackdly = 1 75 85 2 , 5 t 7 hold time, read data after cs* and ds*{rd*} high 1 12 3 , 6 , 7 t 8 cs* or ds* {rd*} high from dtack* low if dtackdly = 0 if dtackdly = 1 25 1 4 , 4. , 8 , 7 t 9 dtack* inactive from (cs* or ackin*) or ds* high 12 3 , 9 , 4 t 10 ds* {rd*} high pulse width 5 4 t 11 setup time, address to ackin* 10 10 , 11 t 12 setup time, write data to ds* {or wr*} low 0 t 13 hold time, write data after ds* {or wr*} high 0 t 14 x_req* deassert after dtack* asserted 2 t clk+30 12 t 15 setup time, r/w* {wr*} and cs* to ackin* low 0 13 t 16 x_req* reassert delay after write to eosrr 2 t clk+30 14 , 15 t 17 ackin* assert/deassert to ackout* assert/deassert prop delay 15 t 18 data bus out of high-impedance after ds* {rd*} low 3 16 t 19 setup time, address to ds* {rd*} during acknowledge cycles 4
CD1865 ? intelligent eight-channel communications controller 138 datasheet t 20 ackout* assert after cs* and ds* {rd*} active on register acknowledge cycles with no match 25 17 t 21 dtack* active pull-up time 18 notes: 1. unless otherwise noted, all values are in nanoseconds (ns). 2. during read cycles, cs* and ds* {rd*} are gated together internally. this specification is with respect to whichever goes active (low) last. 3. during read cycles, cs* and ds* {rd*} are gated together internally. this specification is with respect to whichever goes inactive (high) last. 4. this specification is with respect to whichever goes inactive (high) last. 5. the values given is for 15-mhz operation. the time depends on system clock rate and the chosen dtackdly option. the actual time in any case can be determined by the formula: if dtackdly = 0, then the time is 1.5(tclk) + 30 ns if dtackdly = 1, then the time is 2.0(tclk) + 35 ns 6. this specification is with respect to whichever of ackin* and ds* {rd*} goes active (low) last. 7. the data bus is three-stated immediately after removal of ds* {rd*}. the device is guaranteed to be off the bus by the specified maximum time. the time can be as short as the minimum time. the hardware design should ensure that the data has been read before ds* {rd*} is removed. 4. in multiple CD1865 designs, the interrupt acknowledge cycle must be long enough to accommodate the ackin* to ackout* daisy-chain propagation delay from the first to the last CD1865. ackin* must remain low until after dtack * asserts. 8. for acknowledge cycles, this specification refers to ackin* instead of cs*. 9. during interrupt acknowledge cycles, ackin* is asserted instead of cs*; cs* should remain high. note that ackin* timing is not always the same as cs*. 10.during acknowledge cycles, addresses must propagate through the service match registers. if a service request is pending on this CD1865, the match must finish before ackin* asserts. this is ensured by the specifications. 11.this specification is with respect to ackin* only. 12.this specification refers to one of receive, transfer, or modem service request outputs (rreq*, treq*, mreq*). 13.this specification is with respect to ds*. cs* and r/w* must be high before the assertion of ds* to avoid the possibility of the CD1865 misinterpreting the cycle as a read or write. 14.this is the time required to reassert a service request if the internal conditions of the CD1865 are such that the request should be asserted. 15.this specification refers to one of receive, transfer, or modem service request outputs (rreq*, treq*, mreq*). 16.the data bus is guaranteed to become active after ds* {rd*} low and before data is valid. 17.this is the time for ackout* to assert on register acknowledge cycles. ackout* asserts if the part determines the acknowledgment is not intended for that part. if ackout* asserts, the part does not drive the data bus or assert dtack*. these functions are left to a device further down the daisy chain that accepts the acknowledge cycle. 18.dtack* sources current (drives ? high ? ) until the voltage on the dtack* line reaches 1.5v. at that time, dtack* switches to an ? open-drain ? (high-impedance) state. table 11. unclocked timings (sheet 2 of 2) number description min1 max1 notes
intelligent eight-channel communications controller ? CD1865 datasheet 139 figure 37. unclocked bus interface read cycle, motorola ? -style handshake address r/w* cs*, ds* t 1 valid read data dtack* ackout* t 2 valid t 3 t 4 t 10 t 18 t 5 t 7 t 6 t 8 t 9 t 21 t 20 invalid
CD1865 ? intelligent eight-channel communications controller 140 datasheet figure 38. unclocked bus interface service acknowledgment cycle, motorola ? -style handshake address ackin* ackout* t 11 valid read data dtack* x_req* valid t 3 t 17 t 5 t 7 t 6 t 8 t 9 t 21 t 14 t 15 t 4 t 19 t 10 invalid ds* r/w* cs* t 18 t 17
intelligent eight-channel communications controller ? CD1865 datasheet 141 figure 39. unclocked bus interface write cycle, motorola ? -style handshake address r/w* cs* t 1 valid w rite data dtack* x_req* valid t 3 t 10 t 12 t 13 t 6 t 8 t 9 t 21 t 16 ds* t 4 t 2
CD1865 ? intelligent eight-channel communications controller 142 datasheet figure 40. unclocked bus interface read cycle, intel ? -style handshake address cs* valid read data dtack* ackout* valid t 10 t 18 t 7 t 6 t 8 t 9 t 21 rd* t 3 t 1 t 5 t 20 invalid
intelligent eight-channel communications controller ? CD1865 datasheet 143 figure 41. unclocked bus interface service acknowledgment cycle, intel ? -style handshake address ackin* ackout* t 11 valid read data dtack* x_req* valid t 3 t 17 t 5 t 7 t 6 t 8 t 9 t 21 t 14 t 15 t 4 t 19 t 10 invalid rd* wr* cs* t 17 t 18
CD1865 ? intelligent eight-channel communications controller 144 datasheet figure 42. unclocked bus interface write cycle, intel ? -style handshake address cs* valid w rite data dtack* x_req* valid t 10 t 12 t 13 t 6 t 8 t 9 t 21 wr* t 3 t 1 t 16
intelligent eight-channel communications controller ? CD1865 datasheet 145 11.0 package specifications notes: 1. dimensions are in millimeters (inches), and controlling dimension is millimeter. 2. before beginning any new design with this device, please contact intel for the latest package information. pin 1 indicator pin 1 19.90 (0.783) 22.95 (0.904) 23.45 (0.923) 20.10 (0.791) 16.95 (0.667) 17.45 (0.687) 13.90 (0.547) 14.10 (0.555) 0.13 (0.005) 0.23 (0.009) 1.60 (0.063) ref 2.57 (0.101) 2.87 (0.113) 0.65 (0.026) 0.95 (0.037) 0 min 7 max 0.22 (0.009) 0.38 (0.015) 0.65 (0.0256) bsc pin 100 3.40 0.25 (0.134) max (0.010) min CD1865 100-pin mqfp (jedec)
CD1865 ? intelligent eight-channel communications controller 146 datasheet 12.0 ordering information the order number for the -pin device is: sCD186510qcb product line: part number internal reference number package type: temperature range: revision ? c = commercial mqfp (metric quad flat pack) ? contact intel corporation for up-to-date information on revisions. communications, data
datasheet 147 index a abbreviations 13 absolute maximum ratings 127 access duty cycle 84 acknowledging service requests 44 acronyms 13 addressing intel versus motorola 51 unclocked versus clocked bus 52 b bit rate constants clk = 15 mhz 50 clk = 20 mhz 50 clk = 25 mhz 49 clk = 33 mhz 49 bit rate options 47, 48 bus interface intel versus motorola 51 unclocked versus clocked bus 52 c cascading service 43 CD1865 initialization 84, 88 cd18xx product family cd180 15 cd1864 15 CD1865 15 channel registers channel command 112 channel control status 118 channel option register 1 116 channel option register 2 116 channel option register 3 117 modem change 123 modem change option register 1 124 modem change option register 2 125 modem signal value 125 modem signal value data terminal ready 126 modem signal value request-to-send 126 receive bit rate period registers (high/ low) 120 receive time-out period 120 receiver bit 119 service request enable 112 special character register 1 121 special character register 2 122 special character register 3 122 special character register 4 123 transmit bit rate period registers (high/ low) 121 channel registers, listing of 95, 97 clock options 1 48 2 47 clock oscillator, external 47 clocked bus interface 52, 54, 128 code sequence interrupt 43 polled 42 d daisy chaining 19, 27, 44, 54 device selection considerations 15 e electrical characteristics ac 128 dc 127 external clock oscillator 47
148 datasheet f fair share internal operation 31 interrupt scheme 11 priorities and 31 fifo access 84 empty 35 overflow 33, 61 overrun 33, 58 pointers 27 receive 18, 19, 32, 58, 60, 61 receive data 62 receive exception 18 receive status 32, 61 status 58, 62 timer operations 60 transmit 18, 32, 35 full interrupt type a 36, 37 type b 36, 38 functional description 18 g global registers configuration registers global service vector 102 modem service match 100 prescaler period (high/low) 100 receive service match 101 service request configuration 98 transmit service match 101 miscellaneous registers global firmware revision code 98 service request/interrupt control regis- ters channel access 107 global service channel register 1 106 global service channel register 2 106 global service channel register 3 106 modem request acknowledge 105 receive request acknowledge 105 service request status 103 transmit request acknowledge 105 global registers, listing of 94, 96 h hex address 8-bit 94 intel 94 motorola 94 i i/o operations, basic 90 indexed indirect registers end-of-service request 111 receive character status 110 receive data 109 receive data count 108 transmit data 111 indexed indirect registers, listing of 94, 97 initialization CD1865 84, 88 channel 89 global 86, 89 service request 86 intel addressing 51 intel bus interface 51 interfacing examples 680x0-family processors 55 80x86-family processors 55 vme bus 55 interfacing to the host system full interrupt ? type a 36, 37 full interrupt ? type b 36, 38 polled interface 40 single interrupt 36, 39 software polled 37 internal block diagram 22, 46 internal operation 20, 25 internal service acknowledge 30 internal structure background 24 foreground 24
datasheet 149 interrupt and polled code sequences, compari- son 42 interrupt service modem 92 receive 91 transmit 92 interrupts fair share 11 good data 11 vectored 11 l listing of channel registers 95, 97 global registers 94, 96 indexed indirect registers 94, 97 timing information 128 m modem interrupt service 92 modem pins as input/output 35 modem signal change 35 modes failure 44 flow control 19 idle 84 indexed addressing 18 mixed 26, 37, 40, 45 polled 93 motorola addressing 51 motorola bus interface 51 multiple CD1865s without cascading 44 o off-limit registers 84 operating conditions 127 operations i/o basic 90 interrupt response 90 ordering information 146 p package specifications 145 pin information pin assignments 17 pin diagram 16 polled code sequences and interrupt, compari- son 42 polled interface 40 prescaler 86 priorities and fair share 31 programming examples 88 programming registers 83 q quick reference register map 94 r receive interrupt service 91 receive service requests receive exception 33 receive good data 32 receive timer operation 34 receiving data 88 register description 94 register map 94 register summary 96 registers, programming channel 83 global 83 indexed indirect 83 off-limit 84 s service acknowledge hardware-based 36 software-based 36 service request logic, implementation 28 service requests acknowledging 44 implementing 35 interrupt operation 26
150 datasheet modem signal change 32, 35 receiving data 32, 88 transmit service requests 35 transmitting data 32, 87 types of 31 single interrupt 36, 39 software interface choosing 26 interrupt-driven 26 polled 26 software polled 37 specification, electrical 127 state machine logic 29 system bus interface 46 system clock 46, 47 system interface considerations 47 t theory of operation 10, 26 throughput limits, maximum 51 timing information, listing of 128 timings clocked bus interface clocks 131 read cycle, intel-style handshake 134 read cycle, motorola-style handshake 131 reset 130 service acknowledgment cycle, intel- style handshake 135 service acknowledgment cycle, motor- ola-style handshake 132 write cycle, intel-style handshake 136 write cycle, motorola-style handshake 133 unclocked bus interface read cycle, intel-style handshake 142 read cycle, motorola-style handshake 139 service acknowledgment cycle, intel- style handshake 143 service acknowledgment cycle, motor- ola-style handshake 140 write cycle, intel-style handshake 144 write cycle, motorola-style handshake 141 transmit interrupt service 92 transmit service requests 35 transmitting data 87 u unclocked bus interface 52, 53, 136 v vectored interrupt structure 11

▲Up To Search▲

Price & Availability of CD1865

	To Download CD1865 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .